Re: [RFC] Simplify MinGW canadian crosses

On Sunday 03 September 2006 9:13 am, Keith Marshall wrote:
> On Wednesday 30 August 2006 2:59 pm, Christopher Faylor wrote:
> > FWIW, I forwarded Corinna most of the discussion from this list so
> > she was aware of the problem.
>
> I'm coming somewhat late to this particular party.  I guess I should
> have been subscribed to mingw-patches, but wasn't; we normally discuss
> this sort of thing on mingw-dvlpr.

Just to add my two pennyworth...

On Tue, Aug 29, 2006 at 06:04:06PM +0200, Corinna Vinschen wrote:
> On Aug 29 11:47, Christopher Faylor wrote:
> > Btw, I agree with Daniel's suggestion of using
> > ../config/no-executables.m4 if that's possible.
> 
> I did that first, but the argument against this is that the
> mingw-runtime package, does not contain a top-level config directory.
> The source tree is supposed to be built stand-alone.  Therefore it's
> required to have a stand-alone aclocal.m4 file.
> 
> [time passes]
> 
> Or do you mean I should just add an include(../config/no-executables.m4)
> to winsup/acinclude.m4 and create the aclocal.m4 files from there?

and Daniel Jacobowitz replied: 
> If you do that it'll just emit a sinclude into aclocal.m4 anyway, won't 
> it?

FWIW, aclocal will *never* emit `sinclude'; but that's being pedantic, 
for it *might* emit `m4_include', which amounts to the same thing.

What aclocal actually does emit depends on whether the path to the 
sourced file is specified with an absolute or a relative path; the 
`m4_include' form would be seen with a relative path, while using an 
absolute path results in verbatim copying of the source into aclocal.m4.

It is important that mingw-runtime continues to be maintained as a stand 
alone package; (I checked it out of CVS, as a separate module).  Thus, as 
Corinna points out, it is not appropriate to `m4_include' no-executables 
from its current location in the tree, (which would actually be 
`../../config/no-executables.m4' in this case); if you want to 
`m4_include' it, then you must maintain a separate copy *within* the 
mingw-runtime package tree itself, say in a new `./m4' directory, but 
since aclocal.m4 can itself be reduced to no more than a verbatim copy of 
no-executables.m4, that would seem to be overkill.

Just for the record, I personally prefer to maintain aclocal.m4 by hand, 
rather than generate it using the aclocal tool--which is not an autoconf 
tool, BTW; it is provided by automake, which I utterly loathe and detest. 
Whle aclocal may be convenient, it is also an excellent way to carelessly 
drag in needless dependencies--as an example, consider the GNU libiconv 
autoconfigury, which forces you to distribute config.guess, config.sub 
and config.rpath, together with about half a dozen unnecessary m4 files, 
along with your project, but none of these are essential for a basic 
libiconv client, and by handcrafting aclocal.m4, I can easily eliminate 
the unnecessary dependencies.  (Of course, it isn't the aclocal tool that 
is particularly at fault here--it is a consequence of carelessly written 
m4 sources in the first instance--but using aclocal is lazy, and tends to 
conceal this initial carelessness).

Regards,
Keith.

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642