Re: [lmi] [lmi-commits] master d0ece2a 3/5: Exercise CC as well as CXX

[Greg Chicares]

[removed 'address@hidden' from CC]

On 2018-06-21 23:46, Vadim Zeitlin wrote:
> On Thu, 21 Jun 2018 18:35:41 -0400 (EDT) Greg Chicares <address@hidden> wrote:
> 
> GC> branch: master
> GC> commit d0ece2a38dda00f06ce7067d5a05d174e6905500
[...]
> GC>     Exercise CC as well as CXX
> GC>     
> GC>     Motivation: Additional gcc warnings will soon be enabled. It seems
> GC>     desirable to maintain distinct lists for gcc, g++, and both. In the
> GC>     future, lmi might use C files, as it did in the past, but no longer
> GC>     does until this commit
> 
>  Personally, I think using only one language in a project is preferable,
> unless there is a really good reason to use more than one and I don't see
> why would lmi want to reintroduce C source files.

It's been quite a few years since I considered gcc warning options
systematically, but I'm doing that now. Ignoring the ones that are
particular to FORTRAN or ObjC, there are quite a few that work for
C and C++ both, and some that work for one of those two languages
but not the other.

The makefiles already support for both C and C++. My main objective
is to add more warnings for C++. If I can add some for C at the same
time, the cost is almost nothing, even if the benefit turns out to be
unimportant.

Adding C-only options without testing them is likely to break things.
That's why I wanted at least one C file. This was just the most
plausible candidate.

Alternatively, I could have removed support for C altogether. But
I'm not convinced it will never be useful.

> The only reason given
> here:
> 
> GC>     And it may be more efficient to compile glibc code as C.
> 
> doesn't really seem very convincing to me

That's at best an incidental benefit, which is noted only in passing.

> because I think that compiling
> this code using either C or C++ compiler is a tiny part of the total build
> time in any case. And it just doesn't seem right to have to wonder whether
> a new function should be written to C, to make it compile faster, or C++,
> for all the other reasons.

IIRC, I introduced a C file years ago when I needed a low-level asm
routine that would work the same way across several old msw compilers.
Compiling it once, with gcc, gave me an object file that I could link
into any compiler's C++.

>  IMHO we should stick to C++ everywhere for consistency and simplicity.

I do agree that we should keeping doing that as a general rule.
I'm just not convinced today that we'll never want to make an
exception.