This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]