I respect your objections. This was not intended as a *real* patch. I wanted you to look at the Makefile portion to see if you approved.
As for Perl, I think I can write the script using sh. Perl was just too darn quick and easy.
BTW, the RTC_DEBUG macro isn't mine. I'll see where it came from.
On Fri, Jul 18, 2003 at 01:34:31AM +0200, Wolfgang Denk wrote:
Now for the technical discussion: I don't see much advantage when using your mkconfigx script. IMHO it has several problems:
- It will incorrectly include files that have been commented out using C comments, "#if 0" or similar clauses.
That's an interesting objection.
- It is based on the assumption that only CONFIG_* definitions are relevant; it would be nice if this was the case, but actually there is at least a couple of CFG_* variables, and some boards use (locally) even completely different names
Though this is true, the point is to enable conditional compilation and *not* to allow every configuration option to control Makefiles.
You modify include/asm-arm/processor.h in an unexpacted way (inserting "#undef arm"). Please don't add such code to system header files. Ther eis obviously a problem somewhere in your toolchain and/or on tyour system. Please fix the cause, not the symptoms.
This is to work around a bug. Someone was #define'ing it and breaking a struture. I think that the true culprit is the code that #define's a symbol that isn't all upper case.
May I please ask you to clean up the patch as far as the KEV7A400 dev board is concerned, and resubmit it. Please omit the mkconfigx stuff (and other "goodies" like .gdbinit).
Of course. There's lots of work to do before it is useful.
-*-
Let me elaborate on mkconfigx.
First, I wrote this script to handle the new feature in order to make it easy to enable or disable it. It would be very easy to make it execute only for boards or CPUs that use this configuration feature. Or, when a particular tool was available.
I look only for CONFIG_ constants on purpose. We can have a simple rule: only CONFIG_ constants that define the value '1' will be parsed by mkconfigx.
I'm not sure I'd want to solve the #if 0 problem. Yes, someone could get something that they don't want. On the other handle, it is reasonable to change the definition to '0' from '1' when a feature isn't desired.
The strength of this kind of configuration comes from the fact that it allows the Makefiles to be the arbitrator of what code is included and what is excluded. I've been using it a lot while tweaking the ARM920 builds to accomodate the architectural differences between the Samsung parts and the Sharp parts. There are far too many #ifdefs in the existing ARM920 code making it difficult to figure out what belongs where. This configuration method lets us move the decisions about what belongs where to the Makefile.
So, instead of putting at the top of a source file:
#if defined (CPUA) | defined (CPUB) | ... /* code */ #endif
We put in the makefile
src-$(CONFIG_CPUA) +=start_type_1.S timer_type1.c ... src-$(CONFIG_CPUB) +=start_type_2.S timer_type1.c ... src-$(CONFIG_CPUC) +=start_type_1.S timer_type2.c ...
and move the code to separate files. There are many places where code shares a file for no good reason. I'm looking to put truly ARM920 code in ARM920 triggered sources, and so on.
Cheers.