Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> | I'm not so sure. I still think that calling LT_OUTPUT immediately after
> | LT_INIT is not exactly equivalent to 1.5 behavior.
>
> I think it is equivalent, seeing from a typical configure run with
> libtool 1.5:
>
> Looking at some of the other compatibility macros, how about the
> following instead:
>
> AU_DEFUN([AC_PROG_LIBTOOL],
> [LT_INIT
> LT_OUTPUT
> AC_DIAGNOSE([obsolete],
> [$0: Remove this warning and the call to LT_OUTPUT if you do not need
> libtool to exist before AC_OUTPUT.])
> ])
>
> AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])

That looks OK to me. I'll include something like this in the next 
version of libtool2.2 (or "libtool" test: 2.2).

> | [*] But again, my recommedation is that cygport should NOT run
> | autoupdate in an automated way. Instead, the package maintainer should
> | run it, inspect the results, and fold those changes into .src.patch.
>
> Agreed.
>
> | m4_include([libtool.m4])
> | m4_include([ltoptions.m4])
> | m4_include([ltversion.m4])
> | m4_include([ltsugar.m4])
> | m4_include([lt~obsolete.m4])
>
> While that makes sense, I doubt that would work with the special build
> systems that I'm discussing, at least not in an automated way without
> patching those build systems more than necessary.  I have something else
> in mind, but I'll need to try it out first.

For your packages, do whatever makes your life easier. <g>

> | Sure...just waiting for more input.
>
> Could you post the answer on cygwin-apps?

Sure.

--
Chuck

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/