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

[Mark Brand]

Here is a general question about the subject of native tools within
mingw-cross-env. Sorry if it's been covered before.

Should such tools always have the target prefix (i.e.,
"i686-pc-mingw32-")?  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.


> Consequences of the new guidelines are:
>
>     A)  removal of all *-autogen patches
>
>     B)  three new requirements: autoconf >= 2.50, flex and bison
>
>             (I really hope we won't need anything more,
>              especially no automake, libtool, etc.)
>   

I think you are probably right about flex and bison (although I don't
know about the differences between bison and yacc). Considering the case
of the generated sources for gsoap, I think it's safe to assume that the
author considers the true sources to be the files processed by flex,
yacc or bison, and soapcp2 (which we build in gsoap). The generated
sources are big and predictable. After all, this project is *about* code
generation.

There is also good precedent for requiring flex and yacc/bison.  I'm
pretty sure a lot of source RPMs require these tools.

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.

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's also looking
less practical to use patches for this. The "-autogen patch for this
would be 3.2M!

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. Though time will tell if only one
version will suffice.

>     C)  modification of libodbc++-win32.patch to
>         fix "configure.ac" instead of "configure"
>
> -> Are there other consequences that I missed?
>
>   

To my surprise, I don't find any other cases of this kind.  I also
haven't found any cases of patched Makefiles generated from Makefile.in.

-Mark