On Sun, Sep 17, 2006 at 11:25:02PM +0200, Stefan Reinauer wrote:
- Peter Stuge stuge-linuxbios@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