public inbox for ecos-maintainers@sourceware.org
 help / color / mirror / Atom feed
From: Jonathan Larmour <jifl@eCosCentric.com>
To: John Dallaway <jld@ecoscentric.com>
Cc: ecos-maintainers@ecos.sourceware.org
Subject: Re: Build flag changes [ was Re: Large patch to merge in changes  for  gcc 4.3 ]
Date: Tue, 11 Nov 2008 18:11:00 -0000	[thread overview]
Message-ID: <4919CAAC.50701@eCosCentric.com> (raw)
In-Reply-To: <4919C62F.201@ecoscentric.com>

John Dallaway wrote:
> Jonathan Larmour wrote:
> 
>> Therefore if we're going to be touching all HAL's CYGBLD_GLOBAL_CFLAGS,
>> it's an opportunity to centralise these warning flags, which are entirely
>> generic and are distributed identically across all HALs. I propose adding a
>> CYGBLD_GLOBAL_WARNFLAGS CDL option in hal/common. And I will remove all the
>> standard warning flags[1] from all HALs, and replace it with a reference to
>> that option. More specifically I suggest that CYGBLD_GLOBAL_WARNFLAGS is an
>> option which consists of a concatenation of CYGBLD_GLOBAL_WARNFLAGS_C,
>> CYGBLD_GLOBAL_WARNFLAGS_CXX and CYGBLD_GLOBAL_WARNFLAGS_COMMON. Each of
>> these takes their default_value from an identically named option with a
>> _DEFAULT suffix. This allows package CDL to control the default, as well as
>> letting users override it. It also starts to give us a route to avoid the
>> horrible hackery in pkgconf/rules.mak to eliminate language-specific flags
>> by replacing it with something properly controlled. If anyone has a better
>> proposal, I'd like to hear it, although be warned that if it is more
>> effort, then they can consider themselves automatically volunteered to do it!
> 
> I agree that the rules.mak hackery should be eliminated but your
> proposal appears to involve a lot of CDL editing

Only by script. And this is a step towards eliminating the hackery, but
won't yet do so in isolation.

> and suggests a need for
> updated host tools to read and process the new CYGBLD_GLOBAL_WARN*
> options.

I was intending a default_value for the platform CFLAGS of the existing
options string concatenated with CYGBLD_GLOBAL_WARNFLAGS

e.g.
            default_value { "-mcpu=arm9 -Wall -Wpointer-arith
-Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2
-ffunction-sections -fdata-sections -fno-rtti -fno-exceptions" }

becomes

            default_value { "-mcpu=arm9 -g -O2 -ffunction-sections
-fdata-sections -fno-rtti -fno-exceptions " . CYGBLD_GLOBAL_WARNFLAGS }

This sort of substitution is very amenable to being done by script.

In due course I would expect we'd remove CYGBLD_GLOBAL_CFLAGS and build in
direct host tools knowledge, no doubt with the ever-distant rewritten
makefile generator (then CYGBLD_GLOBAL_WARNFLAGS_C is only used for C
files, CYGBLD_GLOBAL_WARNFLAGS_CXX is only used for C++ files, etc.) But
not for eCos 3.0.

With this change, after the release branch is taken, I can simply change
CYGBLD_GLOBAL_WARNFLAGS_COMMON_DEFAULT to add -Wno-write-strings.

> I'm concerned about the time overhead for debugging and testing
> such changes at a late stage in the release cycle. Could your proposal
> be split into phases to keep changes to a minimum for eCos 3.0 while
> still avoiding multiple edits to the platform HAL CDL scripts?

I'd want to do it by script in any case if it was for more than a handful
of targets, so I don't see any reason not to do all targets.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

      reply	other threads:[~2008-11-11 18:11 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <49190329.8060904@eCosCentric.com>
2008-11-11 17:52 ` John Dallaway
2008-11-11 18:11   ` Jonathan Larmour [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4919CAAC.50701@eCosCentric.com \
    --to=jifl@ecoscentric.com \
    --cc=ecos-maintainers@ecos.sourceware.org \
    --cc=jld@ecoscentric.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).