Suppose at some time we wished to move things like architecture
specific CFLAGS into Kconfig. It would be implemented as a
"string" object and would look something like:
config CPU_CFLAGS
string
default "-march=i386" if M386
default "-march=i486" if M486
default "-march=i586" if M586
default "-march=i686 -malign-functions=4" if MK7
This is terribly simplified, but I think you get the idea.
Suppose someone selects MK7. The resulting .config file
would then have:
CONFIG_CPU_CFLAGS="-march=i686 -malign-functions=4"
Since this file is sourced into the Makefile, we could then
append CONFIG_CPU_CFLAGS onto the CFLAGS. This would also
be kindof cool, since we could add in Makefile macros into the
strings and they would actually be evaluated...
So for the K7 case, we could expand it to something much more
sneaky later on, something like:
default "$(call check_gcc,-march=athlon,-march=i686 -malign-functions=4)" if MK7
and the check_gcc macro could be correctly evaluated by make.
Neat stuff. (Such a check_gcc macro does not yet exist in the
kernel Makefiles, but surely will sometime).
Ok, everything looks fine so far. But now we see a problem...
String objects always contain quotes (") around them. So when
included into a Makefile, we would end up with something like:
gcc -Wall "-march=i686 -malign-functions=4" foo.c -o bar
or similar being run. Because the entire string object value is
quoted, gcc will try to set arch="i686 -malign-functions=4" and
will blow up. Not what we want at all... Dropping the quotes
from the .config file would work, but would probably screw up
other things that need the quotes to work properly. Creating a
new "unquoted_string" data type would work nicely.
Any interest in adding an "unquoted_string" data type ? I dunno
if such a data type is anything you care about, but I can imagine
cool things being done with it, such as the above.
-Erik
-- Erik B. Andersen http://codepoet-consulting.com/ --This message was written using 73% post-consumer electrons-- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/