Re: [Mingw-cross-env-list] Proposal for new guidelines

[Volker Grabsch]

Mark Brand <address@hidden> schrieb:
> Should such tools always have the target prefix (i.e.,
> "i686-pc-mingw32-")?

Whoops, I really forgot that point. But I think we already
discussed that. Here's how I currently handle this:

    *   Packages are free to install their code generators
        to: <>/usr/i686-pc-mingw32/bin, which is their
        ${bindir} by default.

    *   This directory (<>/usr/i686-pc-mingw32/bin) will
        _never_ go into $PATH.

    *   The important generators get a "i686-pc-mingw32-"
        prefix and are copied or symlinked into <>/usr/bin,
        which is in $PATH.

Yes, we currently do have generators in <>/usr/bin which
don't have a prefix, but these are really exceptions.

> Even in cases where there is nothing platform
> specific about the tool? I am thinking of flex, bison/yacc, soapcpp2,
> wsdl2h, and Qt tools, but there are probably more. These could in
> principle be used as-is for any target platform.

I'm not sure whether these generators are really platform
independent. For instance, the "qmake" of Qt isn't!

Even if they are platform independent, they are usually
tied to a specific library version, i.e. the "uic" of Qt
could generate C++ code that uses properties or makes method
calls that older Qt versions won't understand.

The prefix guarantees that these code generators won't
be confused with native ones that generate code for different
library versions and maybe even for a different platform.

Flex and Bison might be exceptions, but I would prefix
them as well, if the ./configure scripts were able to
detect them. (... are they?)

We should be really, really careful about adding tools
to <>/usr/bin that don't have a prefix.

> We already need automake to process patches to Makefile.am. This is the
> case for gsoap and popt, may be the case for vmime, and is likely to be
> the case in the future for freetds.

Okay, so let's add automake to the requirements. However, the
various automake versions are not really backwards compatible,
so I think we should require automake >= 1.10 in order to get
a sane environment.

(Sooner or later, upstream's Makefile.am files will have to
become automake-1.10 compatible anyway. So if we are forces
to fix such incompatibilities, this at least wouldn't be a
wasted effort.)

> I'm afraid it's also going to be hard to avoid needing libtoolize.  I
> ran into this yesterday while working with the latest FreeTDS snapshot.
> I had to patch some Makefile.am files and then "./autogen.sh", after
> which libtoolize was necessary to recreate ltmain.sh.

It it's just FreeTDS, we should consider running automake and
autoconf directly, without calling the "./autogen.sh". As far
as I remember, there is never a real need to regenerate ltmain.sh.
I think it is even copied, not generated.

So let's try without libtool and require it only if it's appears
to be really necessary.

And yes, maybe some packages use outdated libtool versions, but
as long as they cross compile to win32, this is no problem at all.

> As you have pointed out, using automake, autoconf and friends to
> reconfigure a package can introduce problems due to differences between
> versions of these tools. The results will at least be predictable if we
> use a version of autotools that is standard within mingw-cross-env
> instead of the disto's autotools.

Autoconf behaves quite stable since 2.50, the only problem
is automake.

> Though time will tell if only one version will suffice.

As stated above, making sources compatible to the latest
automake is a sensible thing to do anyway, and will hopefully
be accepted by upstream.

So I think we won't need multiple autoconf/automake versions.

Our goal should be to make packages sane rather than building
hacks to support their hacks.

> I think you are probably right about flex and bison (although I don't
> know about the differences between bison and yacc).

The difference is very simple: Lex and Yacc are the original
(proprietary) Unix tools. Flex and Bison are their free software
counterparts. Today, everyone is using Flex and Bison, so don't
worry about Lex and Yacc.

More information:
http://en.wikipedia.org/wiki/Lex_(software)
http://en.wikipedia.org/wiki/Yacc

> I also haven't found any cases of patched Makefiles generated
> from Makefile.in.

Well, this is no surprise.

The "Makefile.in -> Makefile" conversion is not performed by
autoconf, it is performed by the ./configure script during the
build.

In other words: Makefiles are generated by the script that is
generated by autoconf.

Well, all these generators - one quickly confuses them. ;-)


Greets,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR