C vs C++ compilations

[John Dallaway]

Hi Gary

Gary Thomas wrote:

> On Wed, 2003-10-15 at 07:57, Bart Veer wrote:
> 
>>>>>>>"Gary" == Gary Thomas <gary@mlbassoc.com> writes:
>>
>>    Gary> I'm experimenting with GCC-3.3.  This version is starting to be
>>    Gary> *really* picky about some things.  In particular, the eCos Makefile(s)
>>    Gary> use XX-gcc to compile either C or C++ source files, often with
>>    Gary> some C++ only flags thrown in.  This leads to warnings like this:
>>    Gary>   cc1: warning: "-Woverloaded-virtual" is valid for C++ but not for C/ObjC
>>    Gary>   cc1: warning: "-fno-rtti" is valid for C++ but not for C/ObjC
>>    Gary>   cc1: warning: "-fvtable-gc" is valid for C++ but not for C/ObjC
>>
>>    Gary> I'd like to get rid of these and the best way [I think] would be
>>    Gary> to change the rules so that C files are built using XXX-gcc using
>>    Gary> C flags and C++ files are built using XXX-g++ with C++ flags.  I
>>    Gary> also think that over time, the compiler may decide that this is no
>>    Gary> longer just a warning, but an error, so thinking about this now will
>>    Gary> save us in the future.
>>
>>    Gary> Is there any [good] way to handle this?  Can the Makefile generator
>>    Gary> (CDL machine) be set up to handle both C and C++ (probably CXXFLAGS)?

Long-term, it seems that we will definitely need to separate C and C++ 
build flags. We could certainly introduce CYGBLD_GLOBAL_CXXFLAGS 
(similar to CYGBLD_GLOBAL_CFLAGS) and modify the makefile generation 
code to use it. This would not be a huge task, but modifying 100+ 
platforms HALs to accommodate the change might be. I'm not so keen on 
the option of hacking the makefile generation code to treat 'legacy' 
platform HALs differently.

> The attached version [ of the patch ] works fine on my
> PowerPC and ARM targets.  There still are some warnings when there are
> special rules.
> 
> What version (date) of ecosconfig has the support for the full flag set?
> 
> I realize that it will be some effort to split up the CDL and handle
> these problems fully, but as I said I think it's something we should
> address.  The patch could be committed now as it doesn't conflict 
> with any other changes (e.g. using CXXFLAGS)

It seems that your proposed patch constitutes a temporary workaround to 
silence build warnings before we address the real problem. A couple of 
comments:

a) Why do you modify the flags for building both C and C++ files in your 
patch? From your description of the problem, it seems that the flags you 
cite need only be removed when compiling C files.

b) Using the $(filter-out ...) make function to remove a set of flags is 
perhaps more elegant than multiple calls to $(subst ...).

However, I'm wondering whether we should just bite the bullet and split 
out the C and C++ build flags soon rather than introduce a workaround. I 
would be interested in comments from the other maintainers.

John Dallaway
eCosCentric Limited