On Fri, 18 May 2001, Keith Owens wrote:
> 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.
Okay, I see your point now. There's of course the option to have
EXTRA_CPPFLAGS/CPPFLAGS_$@, but most likely Makefile writers will get this
wrong, and it effectively doubles the number of FLAGS variables to track.
> 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.
Okay, I think you're right, the logical separation is not worth the
additional complexity. But why not leave the CPP variable at least?
--Kai
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/kbuild-devel
