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

Attachment: signature.asc
Description: Digital signature

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to