Dear Scott Wood, In message <20101110150307.279a5...@udp111988uds.am.freescale.net> you wrote: > > I was just looking for some consistency so I could figure out what is > being objected to. When something is rejected for specific reasons, > questioning whether those reasons actually imply the conclusion doesn't > seem unreasonable.
I fully agree with you on that. And I want to point out that I really appreciate such discussions. I definitely don't claim to be always right (but when I have my mind set it takes really good arguments). > I wasn't trying to pick a fight -- if you feel this strongly about doing it > that way, then we can live with it. Actually I am not that seriously convinced. I just fear that the other approach introduces a LOT of trouble - way more problems then it ever could solve. > I suppose it depends on whether you view SPL as "this other bit of code > that gets distributed with u-boot and tied into the build system, and > reuses some files" or "a u-boot configuration which is extremely slimmed > down and targetting a different boot environment". For me it is just a part of U-Boot. Usually we do not use separate images, resulting from separate builds, but the SPL and the "real" U-Boot image get bundled into one "NAND boot" image. So for me it seems obvious that these are all just stages of a single build. > > 2) changing make variable settings on the fly during a single make run > > would be a clean solution? I see a lot of potential problems with > > that. > > It is not a single make run. SPL is a separate, recursive invocation > of make. As far as I can see the CONFIG_ variables are not exported. Well, see above. You are argumenting from a low-level, implementation point of view. For the end user this is not transparent at all. He just runs a single "make foo_config" and a single "make all". The end user sees and thinks of just a single configuration and a single build he is running. The fact that we have several build steps is something else. I understand (now, only now!) that you see the SPL part as an independent configuration - such a thought never crossed my mind before. For me it's just a part of the whole build procedure. > > To provide a consistent and debuggable build environment? > > That's precisely why I wanted them separate. :-) > > It keeps the CONFIG_ namespace consistent between C code and > makefiles, and avoids interference from one component to the next. I cannot follow you here. I get the creeps when I imagine to have to track down why a build fails when parameters change on the fly. Did you ever have to track down why some boared config can be build nicely in-tree, but out-of-tree builds fail, but only on SMP machines? and only with >N cores (or fast disks)? I have been there. And I do not want to imagine that the whole environment might change under my feet before I can grab it. > > I have zero interest in debugging the Makefiles for such a build for > > example on a > > SMP system which attempts to run these steps in parallel. Oh, of > > course we must not do that, we must serialize everything? > > Parallel builds should work fine. It would be a separate autoconf.mk > file somewhere under nand_spl, not rewriting the same file multiple > times during the build process. Oh... this is another thing I did not grasp yet. But then, how would it become active for "common" code parts? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de In the realm of scientific observation, luck is granted only to those who are prepared. - Louis Pasteur _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
