On 04.04.2009 11:10 Uhr, Peter Stuge wrote:
Patrick Georgi wrote:
Is it too much for us to ask that the cbfs tool is built and installed into the build system? I think that would be ok.
"into the build system"?
"on the build system" then.
With this patch, it's built in util/romtools and then "installed" into the coreboot-build/*/ directories.
I meant build the tool, then install to /usr/local/bin I like that for romcc as well.
This -- imho -- makes little sense for a tool that roughly takes about a second to compile and serves no other purpose than being a build requirement for coreboot. It would require us to do version checks of the utilities, maintain feature lists of working versions, etc. What a nightmare. Why would we even consider this? Then where would we look for the binaries? /usr/local/bin? /opt/coreboot/bin on non-linux systems? What about Darwin? What about Windows? I really don't think we want to care.
Besides, this discussion has nothing to do with the bug fixed by Patrick's patch.
If that fails, I think it's ok to at least build each of them in their util/ directory and run them there.
We ought to keep our source tree clean and only put objects and binaries to target/.../ but that's as far as we should go.
It would be trivial if we did not insist on build directories, but I don't believe they will go away.
I suppose you meant it is trivial if we use build directories and build everything in there?
At any rate, isn't it actually very easy to build all neccessary tools in a common place and then depend on these in each board?
That way they would only be built once.
Not sure if I get right what you are suggesting. The build tools romcc and romfs are only built once per image. Optimizing 1s per image/target by introducing a whole bunch of new problems and dependencies is an incredibly bad idea.
Stefan