In message 003801c784e0$7923d280$01c4af0a@Glamdring you wrote:
This is not so different from Linux, btw. The only way to configure a Linux kernel is by doing this inside the Linux source tree.
No, the way buildroot works is that you decompress a linux kernel and patch it.
For a board that is fully supported by the kernel.org Linux tree no patching is required, right?
Then you can copy $(LINUX26_KCONFIG) (defined by buildroot make menucconfig) to the $(LINUX26_DIR)/.config.
And then you run thek kernel's config tool and make system. That's what I mean when I said you do this inside the Linux source tree.
This method meet my need to easily be able to select a working configuration for Linux.
Agreed.
I am doing the same for u-boot. A file is copied to include/configs/<board>.h
Yes, that would be the equivalent, and should equally well.
but there are somethings which always needs to change for a new user, and these things need to be configured using buildroot "make menuconfig"
OK. And here is where the problem starts: there is no easy way to generate a "include/configs/<board>.h" from the "make menuconfig" step.
Seems we're back at the technical level now, and I'm happy about this.
One of my main requirements is a consistent interface and ideally everything is using the same configuration system.
Agreed.
The problem with using Kconfig is that it generates a single .config file. It would be nice if it could generate one .config per package. buildroot, linux, u-boot, busybox.
Agreed.
I don't see how I could do anything against out of tree patches even if I wanted, nor am I aware that I ever tried.
You don't allow u-boot to have hooks for out of tree patches.
It seems we are using a different terminology here. To me, a patch is something which you applly using the "patch" progarm or some other automated way like an "sed" or "perl" script etc.
And of course there is nothing I can do against doing this. I can express my opinion that I don't like this because I think that better solutions should be possible, but I cannot stoip you from doing it.
Note, that no "hooks" are needed for doing this.
To be successful, there needs to exists a number of place holders where the developer have total control and simply can copy in out of tree stuff. Relying on patching existing files makes upgrading your out of tree structure unneccessary time consuming.
I fail to see where there is a significant difference between the Linux kernel and U-Boot: you can patch either of the source trees to your liking, and when you copy a "$(LINUX26_DIR)/.config" file for Linux before running "make oldconfig" and "make uImage" you will copy a "include/configs/<board>.h" file with U-Boot before you run "make".
The only difference, and I agree that it is a significant one, is that you cannot easily auto-generate "include/configs/<board>.h" from a Kconfig based configuration system. You would need at least some helper script, but even this should be straightforward to implement.
Instead of doing this, which fixes the problem for you while leaving the rest of the U-Boot community in the dark, we could also discuss if there is a way to make U-Boot configuration easier for all of us.
It seems you prefer the first approach, while I am looking for the latter.
Best regards,
Wolfgang Denk