This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Brian Dessent wrote:
Angelo Graziosi wrote:

and if cygport depend on libtool1.5, how can the user who needs
libtool2.2 install it without uninstalling libtool1.5+cygport+...?

I think cygport should remove its requires: libtoolx.y from its setup.hint. It currently lists that because the default
implementation calls
which itself checks the to-be-built packages' configure.[in|ac] and checks that various autotools are installed. It doesn't do anything special with regards to libtool, except:

    if configure.[in|ac] contains "A[CM]_PROG_LIBTOOL"
      issue a warning that libtool1.5 is incompatible with autoconf-2.13

Now, with libtool2.2, that test needs to also check for LT_INIT, as well as the older A[CM]_PROG_LIBTOOL macros. Furthermore, you can still use cygport even without libtoolx.y installed:

write your own src_compile() method that doesn't call cygautoreconf

"export LIBTOOL=no" before calling cygautoreconf (or "before" calling the default src_compile)

So, really, libtoolx.y is not a requirement of *cygport*, per se, but is a build-depends of whatever you are trying to use cygport to build.

They would have to manually override the warning of setup in order to
install libtool2.2+cygport.

If one install libtool2.2 without removing anything, it overwrite
libtool1.5, and I think this is a little confusing.

And will break things, as the OP pointed out.

Yes, it's not great but it's the best we can do.  Feel free to suggest
something less confusing, subject to the following constraints:

- Both libtools can't exist on a system at once
- Setup cannot express a mutual exclusivity, nor can it cause any
package to be deselected

The only thing I can think of is to wrap both libtool packages in a
postinstall wrapper

Ugh. No, thanks.

In the short term it would probably make more sense to simply drop
libtool from the cygport 'requires:' and instead document somewhere that
you need one or the other installed.

But you don't, really. See above.

Cygport could potentially drop
something in profile.d to do this check and alert the user if
something's wrong, however I dislike the idea of penalizing every
cygport user with yet another task at the start of every login shell.

No, instead cygport itself, inside cygautoreconf(), could perform that check. That is, if LIBTOOL != "no", and configure.[ac|in] contains LT_INIT|A[CM]_PROG_LIBTOOL, then
if ! check_prog libtool1.5 && !check_prog libtool2.2
issue error message about missing libtool

It could also be possible for a cygport postinstall to check for libtool
and only if not found drop something in profile.d that displays a

No need to mess with profile.d; cygport itself can do the check. That way, only cygport users, when actually using cygport, are "penalized" by checking for libtool presence.

Yet another option would be to fix setup to allow more complex
dependencies to be expressed, but that's even more complicated as a)
SHTDI and b) there's always going to be users not using the latest
setup.exe even months/years after a new version is released.

Yep, to both.

In any case, there is no need to wait for the various modifications to cygport. We can (and should) remove the libtool1.5 require: from cygport's setup.hint immediately. (Where "immediately" means "give Yaakov a decent interval to chime in on this thread...")


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]