Features Download

From: Charles Wilson <cwilso11-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f <at> public.gmane.org>
Subject: Re: New packages
Newsgroups: gmane.comp.gnu.mingw.devel
Date: Tuesday 7th July 2009 02:10:26 UTC (over 9 years ago)
On Mon, 06 Jul 2009 16:29 -0300, "Cesar Strauss" wrote:
> In addition, I would add:
> *-any-*       Does not need any platform-specific compiler at all
>               to build. Can be configured with either
>               --prefix=/mingw or /usr, depending on purpose.
> If a package contains only scripts, having no platform-specific binaries
> of any kind, then there is no need to mark it as belonging to any
> platform in particular. Autoconf and Automake fall in that category.
> [ In Debian, where packages are also named differently for each
> architecture, Autoconf only has "all" as the architecture, instead of
> the 12 different architectures for, say, libtool:
> http://packages.debian.org/lenny/autoconf
> http://packages.debian.org/lenny/libtool

In Debian, ALL architectures support posix shell scripts and perl
scripts. In our situation, only msys supports those things.  Naked mingw
does not.

There is a bigger conceptual problem, here.  On Debian, you do NOT
install packages corresponding to the different architectures on the
same file system.  But in our case, we need to.  Now, because the
autotools contain hardcoded references to their installation prefix, you
have an issue with exactly which search path is used to locate m4

If automake goes into the "generic" (e.g. "any") prefix -- say, /usr/ --
then it will look in /usr/share/aclocal for various m4 files.  Now,
suppose also that you install an msys version of libxml into /usr -- so
its m4 files go into /usr/share/aclocal, just as you would expect.

But, you then install a newer version of libxml for mingw into /mingw --
and ITS m4 files go into /mingw/share/aclocal. Further, let us suppose
that the two .m4 files DIFFER.

Without taking special steps, when you use the "any" automake/aclocal,
you will get the .m4 file corresponding to the "old msys" version of
libxml.  Sure there are ways around this.  But they require intervention
by the end user.

However, there's a even BIGGER problem.  The msys-specific autotools are
specifically modified to recognize the -msys- triple, while stock
autotools do not. This is the express desire from Earnie, that the msys
"triple" not "leak" into general circulation.  So, the two versions of
(e.g) autoconf are, in fact, DIFFERENT, and must be installed into
different prefixes.  (This is unlike Debian, where no matter what
architecture you are using, the automakes -- of whatever specific
version -- always go into /usr -- AND there is only one automake1.11 on
the system, not one for msys and one for mingw as in our case [see

Worse, while the autotools themselves are, for the most part, scripts
that ostensibly are cross platform, they contain these hardcoded
references to installation paths -- and paths are NOT cross platform.

So, we really do need two different "trees" of autotools: one
specifically hacked for msys, and one for mingw.  In my vision, the
mingw-target one will include many different versions of automake, two
versions of autoconf, and wrapper scripts to intelligently choose the
appropriate version to use. This wrapper system has worked well for
gentoo and cygwin. BUT I do not plan to do the same for the msys "tree".

> So, we could have: 
> target ting mingw development
>  (--prefix=/mingw)
> ============================
> autoconf-*-any-*.tar.lzma
> automake-*-any-*.tar.lzma
> targetting msys development
>  (--prefix=/usr)
> ============================
> msys-autoconf-*-any-*.tar.lzma
> msys-automake-*-any-*.tar.lzma

And anyway, this ^^^^ does not follow any form of the naming convention
already in effect, as parsed by package.l
In any case, I'm now thoroughly confused by your proposal. First, you
say that the autotools are generic and cross platform, and therefore
should have a subsystem id of "any".  And then you propose two different
versions, both "-any-", but where one is "targetting msys development"
and has a secondary subsys id prepended to the package name.


> Furthermore, if we include platform-independent scripts in a
> platform-dependent package, the result remains platform-dependent.

I do not think the word "platform independent" applies here.  A script
might be cross-platform in general, but the very nature of a script
implies a scripting host.  What we're talking about is
a: pure mingw, cmd.exe only, no msys at all
    bash and perl scripts are do not work here.
    therefore, the "platforrm independence" of these scripts does not
    extend this far.

b: msys (in normal personality):
    bash and perl scripts DO work here, but everything "pretends" to be
    just plain old mingw

c: msys-dvlpr (msys in dvlpr personality):
    bash and perl scripts DO work here, but usually have to be hacked to
    recognized the msys triple

So, bzip2 (compiled with --host=mingw32) contains posix sh scripts that
only work if an msys shell is available.  But the binaries are pure
mingw32 applications. So, in your formulation -- but with the correction
above -- we have some "mingw32 platform dependent" pieces, and some
"msys platform dependent" pieces.  There's nothing that is "platform

I'd cut this gordian knot by saying (a) if the package's functionality
is primarily provided by compiled executables and libraries, then the
fact that it happens to also provide a few ancillary scripts which only
work on msys is immaterial. The --host for the compiled executables
controls, and the "extras" are just carried along for the ride. (b) if
the package's functionality is primarily provided by scripts, that
require an msys scripting host for proper operation, then the --host
STILL controls, even if it makes little difference to the actual content
of the scripts themselves, and even if it differs from the required
scripthost.  e.g. automake-*-mingw32.


Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize

details at: http://p.sf.net/sfu/blackberry
CD: 4ms