Subject:
Re: [nanogui] Microwindows cleanups .... some ideas
From:
Jordan Crouse ####@####.####
Date:
21 Apr 2005 05:00:14 +0100
Message-Id: <42672553.1080908@cosmicpenguin.net>
> a) There's no way to share portions of configuration (I'm targeting
> a couple of different boards -- the basic userland and kernel are
> almost identical, only differing in details -- why shouldn't the
> common part be in a file on its own?)
I'm really not sure what you're trying to say here. Differing in the
details is really what makes this a problem in the first place. Yes,
you are going to have to a bit of redundancy, but the cost of holding
the whole text file isn't high, especially you are going to be storing
the un-common portion of the config for each platform anyway.
> b) Dependencies between modules have to be declared both in Kconfig
> files and in Makefiles.
Again, I'm not following what you are saying. The Makefile handles
dependencies. The kconfig constructs a series of defines that can be,
quite frankly, used anywhere, not just in Makefiles. kconfig has
conditionals, but they are really limited to things like "oh, you're
building a Ipaq? Then you'll need this keyboard, this mouse, and we
won't let you try to build the Zaurus drivers, because they don't make
sense".
> c) Resulting .configs cannot be comfortably human-edited -- sometimes
> you really don't want to do a 'make menuconfig' pass just to change
> something trivial. Well, not "comfortably enough" for me.
Menuconfig is the least useful of the kconfig targets. Changing
something trivial in a .config is as simple as opening the file,
deleting the offending line, and running 'oldconfig', which will prompt
you yes or no for every missing config option.
> d) How do I store comments inside .config, how do I see it during
> 'make menuconfig', how does the configuration step make sure they
> don't get lost?
That is a valid complaint - garbage will be removed by most kconfig
operations. Of course, if you have a well constructed Kconfig, complete
with help text, I'm not really sure what more a comment can tell you. I
suppose I'm not as careful about commenting the dozen or so kernel
config files I drag around all the time.
> In case I'm getting off the track, feel free to educate me. I admit I'm
> not too much of a Kconfig expert -- just my experience from the Linux
> kernel, where it occasionally makes me scream out loud (maybe it's just
> that I got spoiled by BSD's nice'n'friendly config(8)).
Well, I'm not here to claim that kconfig is the greatest thing since
sliced bread, because it isn't, though it has improved since 2.4. But
like I said, many of the more successful embedded projects use it, and
after a long time of dealing with cross compiling packages in a variety
of build systems, you come to respect it and learn to work around its
shortcomings.
> and emit a make fragment + a couple of headers with options. But
yeah, that's
> just daydreaming...
I guess all I can say to that, is that I'm a true believer in rule
number one on this page:
http://openembedded.org/cgi-bin/moin.cgi/Buildsystems_2fRulesOfThumb
>>One of the more pressing issues, though, is getting rid of the absolute
>>paths, and the recursive makes, which drives OpenEmbedded nuts.
>
>
> Hmm, I'm using recursive make with great success for any nontrivial
> project ;-). Out of curiosity, what problems are you hitting?
Well, its not so much recursive makes per say, it is the incorrect way
make handles environment variables across instances of itself. If we
have a environment variable that we wish to take precedence over a
variable in a makefile, we call 'make -e', which works great for the
first instance of make, but it turns out that the flags don't get
carried across to the other instances, so as soon as you get someplace
interesting, your environment variables no longer have any effect.
You can try this at home - change your TOOLSPREFIX to "", and then try
to build Nano-X with another compiler:
CC=foo-linux-gcc make -e
You'll notice that your object files actually get compiled with your
native gcc. Bummer. Of course, if you don't run it with -e, then your
environment variable doesn't get obeyed in the first place, with a
similar result.
Now, there are several ways to fix this, but by far the most obvious is
to simply override the variable in the Makefile as such:
override VARIABLE += MORE TEXT
However, that gets sort of confusing after a while, so most people just
use a different variable name, and then override it at the end.
MY_CFLAGS=-g -O0
override CFLAGS += ${my_CFLAGS)
A far more subtle change, but more confusing would be to reduce most of
the architecture specific mangling that happens in the Makefile rules
down to the CFLAGS and libraries that are specific to that platform (and
have those variables follow the rules detailed above), and call it good.
I think at the very least, we can expect the user to define a CC on
their own without much trouble.
> Or include them in the distribution and provide a reachover build
tree for
> them, which is admiteddly pretty evil as well...
Indeed. Forking that comes from laziness is double plus bad.
Jordan
