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/