Front page | perl.perl5.porters |
Postings from November 2014
On Tuesday-201411-25, 18:00, Tony Cook wrote:
> On Tue, Nov 25, 2014 at 05:39:17PM -0500, Jarkko Hietaniemi wrote:
>> Corollary to 2) What about the -W?
>
> -Wall will just produce noise, and is safe enough.
>
> I think it could go in ccflags.
>
> But again, it should be detected at Configure time, just in case.
>
> Why is this private?
The bumbling person who started this forgetting to CC p5p?
To recap, happened so far...
(1) so I hacked cflags.SH a lot to select a good set of warning and
masochistic options (-ansi/-std=c89) for gcc-ish places
(2) no, -Wall etc. are NOT probed by Configure, NOR used in the
Configure scans, NOR propagated to extensions, either built with
core, or pure-from-CPAN builds with the installed perls. This has
always been the case. Sad. Because this means we have a lot of
warnable extension code out there.
(3) further hacked Config.pm build so that those flags get
recorded in %Config (ccextraflags, ccstdflags)
(4) further hacked EU::MM so that *if* an extension is being
built under core, the flags from (3) are used (hence Yves'
grump attack about 300+ warnings)
(5) furthermore the -std=89 aka -ansi broke the POSIX extension
build under FreeBSD 10.[01] because the new shiny math wants e.g.
<fenv.h> which under said FreeBSD is pure C99 ("inline"), which collides
painfully with C89. (FreeBSD used __inline which is a non-standard
but widely recognized extension, which is not C99, so it's fine
with C89.)
So now I hackily circumvented the (5) failure, but going forward we
need to do something smarter.
TonyC suggests dropping the -std=c89/-ansi from the "if extension
built with core" logic. This might be the easiest way forward.
One might also argue that Configure should do the -W/-std scanning.
This makes sense. But should it itself then use those? If it did use
the -std=c89, in FreeBSD 10.x it would not have found <fenv.h> because
the probe would have failed.
> Tony
>
Thread Next