Mail Archives: cygwin/2008/04/06/18:33:47
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
src_compile()
implementation calls
cygautoreconf()
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 WANT_AUTOCONF=2.1
if configure.[in|ac] contains "A[CM]_PROG_LIBTOOL"
issue a warning that libtool1.5 is incompatible with autoconf-2.13
CYGPORT CODE CHANGE:
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.
CYGPORT CODE CHANGE:
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
> warning.
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...")
--
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 -