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

[Mark Brand]

>> 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?
>>     
>
> 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.
>
>   

Point taken. For some tools, it's not completely clear whether they
should be considered platform-specific. So we err on the side of
caution. If I may try to summarize you, the prefix has the following
benefits:

    It indicates that there is a least a possibility that the tool is
platform specific.

    It indicates that the version of the tool is compatible with
mingw-cross-env.

    It avoids interference with commands of the same name that might be
in the PATH but not provided by mingw-cross-env.

I wonder though how much extra trouble it will be to make a package
invoke, for example, "i686-pc-mingw32-flex".  I'd be surprised if this
"just works".


>> 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.
>   

That's right, and the patches are applied before the configure step.

I think I was thinking about patched Makefile.in generated from
Makefile.am and whether admitting automake into the pantheon will affect
this. Portaudio is the one case of this I find, so it's not much to
worry about.

-Mark