Mail Archives: cygwin/2008/04/08/20:30:42
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/
- Raw text -