This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
Re: C vs C++ compilations
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