C vs C++ compilations

[Jonathan Larmour]

Bart Veer wrote:
>>>>>>"Jifl" == Jonathan Larmour <jifl@eCosCentric.com> writes:
> 
> 
>     Jifl> John Dallaway wrote:
>     >> 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.
> 
>     Jifl> See bug 1000035. The long term solution definitely doesn't
>     Jifl> involve anything like a CYGBLD_GLOBAL_CFLAGS. Flags to deal
>     Jifl> with warnings, optimisation, debugging etc. should be
>     Jifl> brought out separately - there's no reason for most of them
>     Jifl> to be anywhere near a platform HAL.
> 
> Hang on, that has not been decided. Back in the days of pkgconf.tcl
> the handling of compiler flags was designed by committee and we ended
> up with something like 25 different sets of compiler flags. In
> practice this functionality was never really used, it just added a lot
> of complexity to the system for no real gain.

We don't know that either :).

> The existing simple
> GLOBAL_CFLAGS and GLOBAL_LDFLAGS, plus per-package overrides for just
> those, has worked rather well for some years now.

There is only one CYGBLD_GLOBAL_CFLAGS option in each platform HAL. The 
per-package overrides has only become usable in the last year or so since 
we could be more assured people were using updated host tools.

The proposed workaround is clearly just that - a workaround. Common 
options should be gathered into one place so that we never have to arse 
around with adding/removing options across all HALs. The thing is that we 
shouldn't have to use a bunch of workarounds in common files, rather than 
just having the correct common flags in common files.

But anyway, the biggest thing it would help is for custom rules being able 
to extract the correct options they need for special compilations they do, 
rather than all the warning options, optimisation, and necessary 
architecture- (or platform-) specific arguments etc. being lumped together.

As an example, the conversion of libextras.a to extras.o doesn't use 
target.ld, but instead the default tools ldscript, which may not be 
appropriate. However we can't use CYGBLD_GLOBAL_LDFLAGS becuase 
-Wl,--gc-sections at least would screw up the final object.

> OK, the gcc folks have added some complications, and it looks like
> they'll be adding some more in future. It may well be easier to cope
> with these complications in a single place, pkgconf/rules.mak, rather
> than trying to update lots of default settings in lots of platform HAL
> packages every time gcc changes.
> 
> In particular, at some point it may prove necessary for the make
> system to do a $(shell $(COMMAND_PREFIX)gcc --version) and adapt at
> build time to the version of the compiler being used.

Reacting to the host environment is something that is already needed, and 
more than just the gcc version.

> It would be
> possible to do this at the CDL level using a calculated option and
> embedding a Tcl exec command, but I am not sure I want to see CDL
> scripts doing that sort of thing.

You essentially need an autoconf type thing to determine system properties 
and export these as CDL variables. Tricky to do though.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine