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]

Re: automake: 1.4, 1.5, and wrapper

Yaakov S (Cygwin Ports) wrote:

A few requests regarding automake:

1) Could you please include the attached patch in automake1.4?  This
makes automake-1.4 compatible with the other versions in accepting
- --force-missing.  Otherwise, when using autoreconf-2.5x and automake-1.4
together (yes, it does happen), autoreconf -f -i -v fails.

Sure, no problem.

2) Could you please package automake1.5 as well? freeglut uses it.

Errr...okay. I had originally planned to have the whole rainbow (1.4-1.9) but for some reason -- which I cannot remember right now -- I ended up not doing 1.5. I wonder why...

Anyway, I can do this.

3) In addition, it is possible to have a wrapper for automake with our
setup.  Gentoo has a similar setup, and uses this:*checkout*/sys-devel/automake-wrapper/files/

BTW, they have a different autoconf wrapper also:*checkout*/sys-devel/autoconf-wrapper/files/

Hmm. Well, for autoconf, I like using a bash script instead of perl -- lighter weight. And as long as it is SEP[*] to fix the non-cygwin-specific bugs and maintain it, I don't care where the original derives: Red Hat, Mandriva, Gentoo. Doesn't matter to me.

[*] Somebody Else's Problem

However, for automake, I've got a few issues.

#1: a decent -- not massive, but significant -- amount of work involved for me, vs. negligible(?) benefit for users. Creating new versions of ALL packages, where each post-install/pre-remove script is modified to eliminate use of alternatives system. Docu updates to remove references to update-alternatives... etc.

#2 transition plan from alternatives-system to wrapper script is problematic: users *must* upgrade ALL automakes simultaneously, as well as installing the new wrapper package, or serious breakage occurs. This is because the preremove scripts of the existing automakes will continue to make the altern. symlinks until there are no more members of the class. Only THEN is the top-level symlink removed, allowing for the wrapper to be installed in its place.

#3 cui bono? The only advantage of a wrapper system, as opposed to the status quo, is that you don't need to set the current alternative manually to match the desired version, when using autoreconf or a bootstrap/ script. When using enable-maintainer-rules, even under the current system you don't need to worry because the proper version of automake is called explicitly.

But wrappers are sometimes wrong, so you need to manually set WANT_AM_FOO. When you get right down to it, what's the diff between that and update-alternatives?

On a multiuser system -- most cygwin installations are not -- there is a significant benefit in that userA and userB are not forced to have the same version set as their default. But I don't see that playing a very large role in cygwin.

I'm going to need an actual use-case demonstration of failure of the current system, before I worry about going thru the effort of re-introducing wrapper scripts for automake.


-- Unsubscribe info: Problem reports: Documentation: FAQ:

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