nanogui: Microwindows cleanups .... some ideas
Subject:
Re: [nanogui] Microwindows cleanups .... some ideas
From:
Jachym Holecek ####@####.####
Date:
21 Apr 2005 02:05:41 +0100
Message-Id: <20050421010537.GB13582@merlot.ics.muni.cz>
Hello,
> > I don't find 'make menuconfig' particularly exciting (and once you
> > want to maintain a number of different configurations, it gets about
> > zero-useful).
>
> Its not the 'menuconfig' part of kconfig that is interesting, its the
> configuration file. And for multiple configurations, it actually does
> turn out to be a life saver. I offer up as evidence busybox and uclibc,
> two very popular embedded projects that use kconfig to great success.
I see. Kconfig provides quite a good infrastructure for defining possible
options, but it has a couple of problems too. Randomly off the top of
my head:
a) There's no way to share portions of configuration (I'm targetting
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?)
b) Dependencies between modules have to be declared both in Kconfig
files and in Makefiles.
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.
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?
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)).
Ideally, config would consume a file like:
include "foo/generic.cf"
use package1 # Warn if package1's dependency has been ommited
use package2 { option1 option2 }
and emit a make fragment + a couple of headers with options. But yeah, that's
just daydreaming...
> 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?
> If we're going to use outside packages (libpng, ft2, etc) then we need
> to start embracing the dark side of pkgconfig and other such evil yet
> useful tools.
Or include them in the distribution and provide a reachover build tree for
them, which is admiteddly pretty evil as well...
Regards,
-- Jachym Holecek
