Subject:
Re: [nanogui] Microwindows cleanups .... some ideas
From:
alain volmat ####@####.####
Date:
23 Apr 2005 14:05:41 +0100
Message-Id: <20050423130512.90748.qmail@web41713.mail.yahoo.com>
Using kconfig in nanox is really in my wishlist.
however I am wondering what we should do concerning
compilation for platform other than linux ? Currently
nanox can (never tried but .. at least there are some
makefiles) also compile DOS (at least) ..
what should we do for those platform ? I'm not sure we
can also use kconfig on those platform ... :D
moreover are there still people using the several .mak
file there are all over the nanox tree ?
Alain
--- Jordan Crouse ####@####.#### wrote:
> > 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
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> ####@####.####
> For additional commands, e-mail:
> ####@####.####
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
