On Mon, Aug 11, 2014 at 01:18:40PM +0300, Igor Grinberg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 08/10/14 14:14, Tom Rini wrote: > > On Sun, Aug 10, 2014 at 11:49:12AM +0300, Igor Grinberg wrote: > >> > >> > >> On 08/07/14 20:33, Stephen Warren wrote: > >>> On 08/07/2014 10:57 AM, Tom Rini wrote: > >>>> On Thu, Aug 07, 2014 at 04:17:21PM +0300, Igor Grinberg wrote: > >>>>> On 08/07/14 13:57, Tom Rini wrote: > >>> .. > >>>>>> we just need > >>>>>> /usr/bin/env python2 as how we invoke our scripts. > >>>>> > >>>>> This means impose python version dependency for U-Boot source build? > >>>>> Correct me if you think I'm wrong, but I don't think this is a good > >>>>> practice... > >>>>> I think that for tools like buildman, patman, etc. - this is > >>>>> perfectly fine to impose an interpreter/compiler version, but not > >>>>> for the basic source builds. > >>>> > >>>> I agree. You don't need MAKEALL or buildman to do basic source builds. > >>>> Doing 'make foo_defconfig' doesn't require re-creating boards.cfg. > >>>> > >>>> To me, the gray area is people doing SoC level (or higher) changes that > >>>> want to be good and test more areas. That's when MAKEALL or buildman > >>>> become handy and some sort of win over a shell forloop. > >>> > >>> Why on earth isn't relying specifically on either Python2 (with the > >>> current script code) or Python3 (after porting the code) a good practice? > >> > >> Because I think (I can think this way, right?) it is not a good practice > >> to bring another host machine dependency (moreover, version dependency) > >> for the simple source code build (now it also backfired in OE). > >> > >>> Banning or replacing the use of Python just because they cleaned up their > >>> language seems like poking your eye out to spite your nose (or whatever > >>> the expression is). The same thing will happen with Perl, and happened > >>> with dtc, etc. > >> > >> Did I say ban python or something? No, I did not say that. > >> What I'm saying is: > >> Right now, we have compiler dependency (a must as you can't practically > >> produce any code without it), and we have dtc (a must if you want to > >> compile dts), and we have make, and we have shell (this one is found > >> on every host, although windows users have to use cygwin or such, > >> but who cares, so no problem), and now we also add python to the soup? > > > > Maybe I'm being thick then. What's the use case you need MAKEALL or > > buildman for? > > Now, I feel like we are talking about different things... > I'll try to be a bit more clear on this: > > Simple use case: build U-Boot for a board: > ================================ > $ make mrproper && make cm_t335_config && make -j12 > /dev/null > CLEAN examples/standalone > CLEAN tools > CLEAN u-boot.lds > CLEAN spl/arch spl/board spl/common spl/disk spl/drivers spl/fs spl/lib > spl/spl spl/u-boot-spl spl/u-boot-spl.bin spl/u-boot-spl.lds > spl/u-boot-spl.map > CLEAN u-boot.map u-boot.bin u-boot.srec u-boot u-boot.img MLO System.map > CLEAN include/generated spl > CLEAN include/autoconf.mk include/autoconf.mk.dep include/config.h etags > HOSTCC scripts/basic/fixdep > GEN /home/grinberg/bin-temp/u-boot/Makefile > File "/home/grinberg/git-repo/u-boot/scripts/multiconfig.py", line 344 > print "*** Default configuration is based on '%s'" % KBUILD_DEFCONFIG
Ug, crap, OK, I had missed that one. Masahiro, how hard would it be to turn multiconfig.py into a bash script? Or even handle it within make? -- Tom
signature.asc
Description: Digital signature
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
