On 6/4/2010 4:02 PM, Earnie wrote:
> I don't see anything out of line. I do question having autoconf-mingw
> and friends instead of autoconf-msys in the msys-dtk package.
autoconf-mingw and friends are the ones you're supposed to use when
developing MinGW apps. That's what the msys-dtk is FOR, right?
OTOH, autoconf-msys and friends are the ones you /must/ use when
developing MSYS apps (for many reasons, outlined below); that's why
autoconf-msys and friends are in the msys-system-builder (approximately
equivalent to msys-dvlpr) along with msys-gcc and msys-binutils.
This is also why there's only ONE version of msys-autoconf and
msys-automake; while on the mingw side we have a wrapper system and both
autoconf-2.13 and autoconf-2.6x, and all of automake-1.5,1.6...1.11.
For our users, who develop MinGW apps using mingw-gcc, provide
everything. For msys developers, the requirements are much more modest.
> It just
> doesn't sound feel right. I'm sure it has been stated before but what
> is the advantage to autotools-mingw vs autotools-msys?
It's not an "advantage" -- it's a necessity to have distinct autotool
toolchains for msys and mingw. For several reasons:
[Sigh. I need to make a keyboard macro for this. I feel like I've
explained it twelve times over the past four years...]
$(prefix) is compiled in. The autotools (by which I mean autoconf,
automake, libtool, and gettext -- with its dependency libiconv) rely
heavily on data files located in some defined subdirectory under
$(prefix). Sometimes that directory is hardcoded in binary form, in
other cases its hardcoded in a script. Gettext and libiconv DO have
support for "relocability" -- so they can be installed somewhere other
than their compiled-in $(prefix) and yet still locate the necessary
support files, so long as their location relative to where the
binary/script is installed remains constant. However, autoconf,
automake, and libtool do not. It's beyond my purview to try to add that
Given the above, one other data point: all of the autotools that are
intended to work together must all have the same $(prefix). You can't
use /opt/foo/bin/autoconf with /bin/automake. (Well, you CAN, but there
will be problems: solvable, but we do NOT want to borrow trouble. Our
users want tools that Just Work.)
gettext, libtool (and libiconv) provide binary components, not just
scripts. Specifically and most importantly, the libltdl and libintl
DLLs. Obviously, MinGW applications will rely on mingw versions of
these DLLs, and MSYS applications will rely on the msys versions.
Therefore, we need msys-gettext and mingw-gettext, msys-libtool and
mingw-libtool, msys-libiconv and mingw-libiconv. However, msys-gettext
and mingw-gettext can't both have the same $(prefix) [ditto libtool,
libiconv]. Even if the DLL names differ (and they do: msys-intl-8.dll
vs. libintl-8.dll), the headers and import/static libs do not, so the
files will clash. More importantly, we do NOT want any msys .a's to
show up in the default MinGW-gcc search path (nor mingw .a's in the
msys-gcc search path). Same goes for headers. And, for officially
distributed packages, we DO want the msys headers and .a's to appear in
the msys-gcc search path, and we DO want the mingw headers and .a's to
appear in the mingw-gcc search path.
This means that msys-gettext (and msys-libtool, and msys-libiconv) need
to be compiled with --prefix=/usr, while mingw-gettext (and
mingw-libtool, and mingw-libiconv) need to be compiled with
--prefix=/mingw (or, rather, `cd /mingw && pwd -W`, where this does not
impact scripts. [because scripts, executed by msys-bash or msys-perl,
won't grok 'C:/MinGW' -- they need /mingw].
Taking all of the above, this means that mingw-autoconf and
mingw-automake need to be compiled and installed where
mingw-gettext|libtool|libiconv are: /mingw. And msys-autoconf and
msys-automake need to be compiled and installed where
msys-gettext|libtool|libiconv are: /usr.
Finally, there is the issue that the msys variants of these packages
actually DIFFER from the mingw variants, and we don't want to mix them.
For instance, as a consequence of your decision NOT to allow MSYS
modifications to propagate "upstream" (specifically, config.guess and
config.sub changes for *-msys-*) we MUST have a special version of
autoconf and automake which DOES have those changes, simply so that we
can use them for building -msys- packages. But, suppose somebody used
these msys-hacked versions to maintain their "foo" package. When they
autoreconfed, they'd get copies of our msys-modified config.guess and
config.sub scripts -- and their next official foo-2.4.2.tar.bz2 source
release would "leak" these msys mods into the wild. You, Earnie
specifically, don't want to do that. With the current "split"
arrangement, it can still happen, but is less likely -- since the
"normal" mingw autotool packages are the "preferred" ones.
So, we want the "normal" autotools that we tell everybody to use --
except us masochists building msys apps -- to be unmodified (or, as
unmodified as possible while still working properly, and where those
modifications are all candidates for pushing upstream). I admit, I've
been slow getting the cygwin/mingw libtool mods accepted upstream, but I
dare anyone to claim I haven't been trying (grumble, curse, grumble).
AND, don't forget that OTHER packages install .m4 files and other items
into $(prefix)/share/aclocal/ and related locations. We have a
libxml.m4 in /usr/share/aclocal/ because we have an msys-libxml2
package. But, you wouldn't want somebody maintaining some mingw package
to accidentally pick that up, when we DON'T have a mingw-libxml package.
If they NEED libxml.m4, then that highlights an actual need: their "foo"
package has an unmet mingw-libxml2 dependency, and they have some
additional work to do... (*)
Also, non-autotool MSYS packages may (I don't think any do NOW, but they
COULD) install modified versions of the .m4 files. A related example is
/usr/include/lzma.h: it is SERIOUSLY hacked up to accomodate our missing
<inttypes.h> and <stdint.h> files. Now, that's just a header file, and
mingw-gcc's search path won't look in /usr/include; but what if an .m4
file was modified similarly? We don't want to propagate MSYS changes
upstream, but we also don't want them to "leak"...
(*) I still have a concern about "config" scripts and .pc pkg-config
files. For instance, msys-libxml2-dev installs /usr/bin/xml2-config.
When configuring a Mingw package /mingw/bin is still in the front of
PATH, but /bin IS also in it. So, the configure script will "find"
/usr/bin/xml2-config, and will "think" that libxml2 is installed. Worse,
it'll use xml2-config's output to add -L/usr/lib to LDFLAGS, -lxml2 to
LIBS, and -I/usr/include/libxml2 to CFLAGS. But...(a) we don't have
very many such scripts or .pc pkg-config files, and (b) VERY few people
will ever install the msys-*-dev packages that contain them, so...not
borrowing trouble, I'm ignoring the issue. <g>
The following blurb appears in *every* .RELEASE_NOTES.txt file
associated with the 16 (mingw,msys)x(autoconf*, automake*, and libtool)
packages, if not with the (mingw,msys)x(gettext,libiconv) ones:
For a discussion of the packaging standards used by the MinGW
project for pre-built components -- especially as related to
the autotools such as autoconf, automake, and libtool, see:
and here: http://article.gmane.org/gmane.comp.gnu.mingw.devel/3305
If you're REALLY curious, the following threads are quite
informative, if extremely long, and detail the discussion and
reasoning behind the current packaging schema. Presented in
reverse chronological order:
2009-06-21 22:38:19 GMT
"GCC 4.4.0: Naming conventions"
2009-04-18 06:35:28 GMT
"Standards for Building MinGW Release Packages"
2008-03-27 12:36:25 GMT
Now, in one of those first two threads, we discussed ad nauseum the
proper *names* to apply to these two variant autotool toolchains. I'm
not going to rehash it here, but we eventually settled on:
(1) the MSYS DVLPR (System Builder, hacked up for msys and installed
into /usr) versions would claim the subsystem "msys"
(2) the MSYS DTK (e.g. "normal" versions installed into /mingw) would
claim the subsystem "mingw32" -- even though, for autoconf and
automake particularly, they don't work AT ALL without a supporting
MSYS installation complete with msys-perl, msys-m4, and msys-bash
Now, I don't think anybody is going to argue that the Developer Toolkit
*shouldn't* have autoconf and automake? And that the autoconf and
automake versions it includes should be the ones that are intended for
use when developing applications for MinGW, rather than MSYS?
But most of the DTK's contents are msys tools: perl, m4, and the like.
So, by necessity, it has both "msys" subsystem components -- and by
virtue of the decision outlined above, "mingw32" subsystem componenets.