[LinuxBIOS] v3(?) config [was:changes in decompress coming.]

[Peter Stuge]

On Sun, Sep 17, 2006 at 11:25:02PM +0200, Stefan Reinauer wrote:
> * Peter Stuge <stuge-linuxbios at cdy.org> [060917 02:37]:
> > Fair enough. But does the build directory have to be per-target or
> > would you be OK with fixing the build directory to e.g. build/ right
> > next to src/ ?
>  
> The advantage we have now is that we can easily put config files
> for "build with VGA" "build with FILO" "built with etherboot"
> "build 256k/512k/1MB" etc. If we can easily fix this, we might be
> able to drop the hierarchy in /targets

We absolutely need a way to set those high-level options in a
simple-as-can-be manner.

Config.lb works very well but is a clumsy user interface.

I dislike needing to buildtarget (and the cd:ing and rm:ing that
comes with it) before make. I just want one step for config and
one for build.

The other main problem is that users are forced into expert mode
(fdisk analogy) because they need to set the payload path.

Maybe we can get away with a Kconfig frontend for the existing
system? The expert mode may still be too advanced though.


> > What I like about the Linux build is that there's only ever one dir
> > that you "make" in, and when make is done it always produces
> > arch/*/boot/bzImage.
>  
> Good comparison. So "config" in our case is actually what we have in
> /targets/ now. The tree is not. Which board we build for is a config
> option though.

Yes. As a user I don't think about the tree at all. Most of the time
I don't have to. Sometimes I may want to disable a specific device
that isn't populated on my board if the vendor is silly enough to
have such options without changing the board name but I shouldn't
have to become a developer to do so.

Maybe we could work around it by creating our own names for those
variations, but with a few options on a board it gets messy.

If it's enough for users to only disable devices maybe we want to
split developer config (tree) from user config, even if they in
effect control the same thing. (tree AKA what code to include)


> > The current structure could be simple too, if the buildtarget step
> > could be skipped, and there was no need for via/epia-m/epia-m but
> > only via/epia-m, and that's where you go to make config && make to
> > get a linuxbios.rom.
> 
> ready-made config directories? With Kconfig this could be a lot
> easier because it resolves option dependencies during compile time.

The current system is optimized for building every target. I think
abuild is the only one who actually does this and hence we should
optimize for the common case; building only one target.

I don't think we need the extra layer of abstraction, at least not by
default.

cd targets/via/epia-m # determines which tree to start with
make config # determines what the user wants to set
make # builds linuxbios.rom

Better yet, skip cd and pick mainboard in make config. In root:

make config
make # creates build/linuxbios.rom, maybe build/lb-2.0-filo-512.rom?

Have one expert option be "build directory" and abuild stays happy.

Only problem left is expressing dependencies in a way that make
understands. Sorry if I've been slow to catch up.

Sticking with python maybe scons would be an alternative? xmms2 uses
it - while they are friends of mine that I have a lot of respect for,
technically and otherwise, I still believe that make is good enough
at dependencies. :) May just be inexperience though.
http://www.scons.org/


> > > yes, kconfig has real limits, and we need to see if we can work
> > > our way around them.
> > 
> > Or maybe we'll extend it?
> 
> Or use it for what it can do and use different "made-to-the-task"
> utilities for the rest of our needs.

Check!


//Peter