X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Message-ID: <47FB83D4.5080600@cwilson.fastmail.fm>
Date: Tue, 08 Apr 2008 10:40:20 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Attn: cygport maintainer [was: Re: Libtool 2.2.2]
References: <47F6A816 DOT 2010208 AT alice DOT it> <47F73BA6 DOT 6000001 AT alice DOT it> <47F7E1D1 DOT 804DF919 AT dessent DOT net> <47F94F88 DOT 6050705 AT cwilson DOT fastmail DOT fm> <47F9A114 DOT 3060608 AT users DOT sourceforge DOT net> <47F9B6B6 DOT 4090908 AT cwilson DOT fastmail DOT fm> <47FA254B DOT 205 AT users DOT sourceforge DOT net> <47FB0E98 DOT 3060402 AT cwilson DOT fastmail DOT fm> <47FB25D3 DOT 6040703 AT users DOT sourceforge DOT net>
In-Reply-To: <47FB25D3.6040703@users.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

Yaakov (Cygwin Ports) wrote:
> Charles Wilson wrote:
> I'm now looking at 2.2, what I mean is instead of (in libtool.m4):
> 
> AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
> AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
> 
> Do something like the following:
> 
> AU_DEFUN([AC_PROG_LIBTOOL], [
> LT_INIT
> LT_OUTPUT
> ])
> AU_DEFUN([AM_PROG_LIBTOOL], [
> LT_INIT
> LT_OUTPUT
> ])
> 
> AFAICS that would allow full compatibility with 1.5 behaviour after an
> autoreconf.

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 that is too 
early...but I don't know how to force a non-local insertion of 
LT_OUTPUT, and even if I did, I don't know how "far down" in 
configure.ac that non-local insertion should go.

Of course, if you KNOW of a package that needs libtool before configure 
is finished (I don't), you could easily test my assertion by manually 
inserting LT_OUTPUT immediately after A[CM]_PROG_LIBTOOL/LT_INIT, 
manually running autoreconf with libtool2.2, and see if it works...

But even so, this means that as part of cygport [*] you'd need to run 
autoupdate, which is not the current behavior.

[*] 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.  In 
which case, manually adding LT_OUTPUT before generating .src.patch only 
when necessary rather than relying on autoupdate to do it automatically 
always even when unecessary, seems to be the better way to go.

>  But I see now that this would cause LT_OUTPUT to be added
> by autoupdate, which would generally be unnecessary. 

That's a drawback, all right.

> Is there another
> way to do this?

I don't know.

> True, but I don't think that's the primary reason to have only one
> libtool, and isn't the idea that it shouldn't be necessary to switch
> back and forth?

Well, yeah -- in a perfect world.

> | Besides, libtool-2.2 compatibility patches are the sort of thing
> | upstream maintainers like to see...
> 
> There is another case which might be tricky.  Some packages (namely
> Berkeley DB and KDE3) ship with libtool.m4 and then cat(1) it into
> aclocal.m4 (BDB) or acinclude.m4 (KDE3).  With 1.5, cygport simply
> copies the libtool.m4 (and ltmain.sh) over the shipped copy in these cases.
> 
> With 2.2, besides the change in location (the /usr/share/libtool/config
> subdir didn't exist in 1.5), there are now several libtool m4 macros.
> Besides ltdl.m4 and argz.m4 (AFAICS required only by ltdl.m4), are they
> all necessary for a working libtool.m4?

Correct. The gcc folks ran into this. FWICT, you need each of: 
libtool.m4, ltoptions.m4, ltsugar.m4, ltversion.m4, lt-obsolete.m4,

It is recommeded, instead of copying those contents into aclocal.m4, 
that instead you do:

m4_include([libtool.m4])
m4_include([ltoptions.m4])
m4_include([ltversion.m4])
m4_include([ltsugar.m4])
m4_include([lt~obsolete.m4])

> | Well, Ralf seems to agree.  I'd like to hear from a few other
> | maintainers before taking that plunge though. (For now, just don't
> | install the "new" libtool2.2 package, and you'll be fine).
> 
> Please do that ASAP so that I can make the necessary changes in cygport.

Sure...just waiting for more input.

> | So, "please remove the libtool1.5 dep from cygport. Full stop."
> 
> I don't see another choice for now, but if there becomes only one
> libtool package, I would add it back.

I have modified cygport's setup.hint on sources.

--
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/