Re: [MinGW-dvlpr] =?iso-8859-1?q?=5BMingw-users=5D_ming32-make=3A_inf?= =?iso-8859-1?q?inite_recursion=09when_using_-C_and_=26=26?=

[Keith M. <kei...@us...>]

On Friday 16 March 2007 12:25, Earnie Boyd wrote:
> Quoting Greg Chicares <chi...@co...>:
> > but at the cost of losing the distinction between '.C' and '.c'.
>
> You mean within make itself.  If GCC gets .C when it should be .c
> then you'll cause yourself some grief because .C indicates to GCC
> that it is C++ source and it will switch to the G++ frontend for
> compilation.

IMO, that's a dangerous distinction to try to preserve anyway, when the 
underlying file system doesn't genuinely treat the two as distinct; 
much safer to standardise on .cc, or better still .cpp, (I understand 
MSVC recognises the latter, but not the former), for C++ code.

> >> In addition to those options I've suggested, we should also
> >> specify an appropriate set of CFLAGS, in the $configure_options. 
> >> The PORTNOTES file suggests that you would have used CFLAGS='-s
> >> -O3 -mms-bitfields'; is there anything else we should consider?
> >
> > Flags '-s -O3' seem good for a prebuilt binary.
>
> Yes, for the trustworthy source.  03 causes inlining that may cause
> trouble you can eliminate with 02.

So, some really rigorous testing should be mandatory, if we choose -O3.  
That could be a problem, since the provided testsuite absolutely 
refuses to *build*, never mind run.  Safer to stick with -O2, I think.

> > I think '-mms-bitfields' may be unnecessary. Searching for it on
> > the make-w32 mailing list, I find only messages from Earnie;
> > perhaps it's just a flag he generally uses out of habit, and not
>
> Definately.  -mms-bitfields is more useful for the library modules.
>
> > The just-cited message specifies '-march' and '-mtune'. I don't
> > suppose it matters much to optimize 'make' itself, because it's
> > the commands 'make' runs that are probably costly; but I've
> > never taken measurements. It also specifies 'enable-largefile';
> > if that would only permit unimaginably large makefiles, then I
> > don't see any practical advantage to it.
>
> -march should not be specified for a distributed binary or if
> specified should have a value of i386.  If you are building from
> source then by all means do specify it.  In the mingwPORT files I
> create I specify -march=`uname -m` so that the user can have the best
> optimization.  The -mtune on the otherhand should be specified for a
> distributed binary so that if available some optimizations will occur
> at runtime.

Seconded.  -mtune=i686 seems a good bet, but we need to maintain 
-march=i386 compatibility; (I know some users who still want to use 
Win98; dunno why, dot then I don't really want to use WinANYTHING :)

> >> Just one final thought; should we not be including at least the
> >> COPYING file, in the binary distribution?  (I'm not sure where it
> >> would be most appropriate though).
> >
> > Actually, I don't find anything in the GPL that requires that,
> > as long as we offer 'COPYING' as part of the sources.
>
> It is also the license by which we offer the binary so yes, COPYING
> should be part of the distributed bundle.  I like to put it in a
> doc/make directory.

That seems ok to me too.  One other thing: I notice that info/dir seems 
to be in the current tarball.  Please remove it from future packages; 
it breaks any existing info configuration on the install host.

Regards,
Keith.