On Fri, 18 May 2001 09:41:51 +0200 (CEST),
Kai Germaschewski <[EMAIL PROTECTED]> wrote:
>On Fri, 18 May 2001, Keith Owens wrote:
>> I plan to remove CPP and CPPFLAGS, replacing $(CPP) with $(CC) -E
>> throughout and merging CPPFLAGS into [AC]FLAGS. This change will make
>> it much easier to handle implicit dependencies in kbuild 2.5.
>
>I don't see this, can you explain it further? CFLAGS is set to
>$(CPPFLAGS) + compilation flags, whereas the preprocessing of course only
>needs $(CPPFLAGS). Well, currently it's not done cleanly at all, i.e.
>-D__MODULE__ -include ... etc. are added directly to the command line and
>aren't part of $(CPPFLAGS), but that's fixable.
That is precisely my problem, it is not done cleanly at the moment.
We currently have, in roughly this order
global cppflags in top level makefile
include list from top level makefile
module/kernel flags from top level makefile
global cflags in top level makefile
extra cflags for entire directory from makefile
extra cflags for individual file from makefile
The last two are called EXTRA_CFLAGS and CFLAGS_$@, even though they
almost always contain preprocessor flags. Some of the preprocessing
steps are missing some flags, I just got a bug report that genksyms
does not get extra cflags from the directory or file so the modversions
calculation is not always correct.
For 2.5 I want users to be able to specify extra flags at the global,
directory and file level on the command line, without having to edit
the makefile. We sometimes get patches sent out with debugging options
turned on the makefile because somebody forgot to remove their
debugging change. So the list will be
global cflags from top level makefile
global extra cflags from command line
include list from top level makefile
module/kernel flags from top level makefile
extra cflags for entire directory from makefile
extra cflags for entire directory from command line
extra cflags for individual file from makefile
extra cflags for individual file from command line
If I maintain the semi-separation between preprocessor and other C
flags then it gets very messy when most of the extra cflags are really
being used for preproessing options. I would have to include almost
all flags in the preprocessor steps anyway, just in case they affected
cpp. So why have an artificial separation that only affects a couple
of cases, has been a source of error and AFAICT provides no benefit?
It is a lot easier to say that all steps get all flags and let the
preprocessor and compiler work out which bits they want.
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
