Environment in Makefiles

Alexander E. Patrakov patrakov at ums.usu.ru
Sat Jan 14 20:49:16 PST 2006


Jeremy Huntwork wrote:

>Alexander E. Patrakov wrote:
>  
>
>>This simplification is important for me because it allows easily
>>replacing all "chroot" commands with, e.g., invocations of
>>qemu-system-x86_64.
>>
>>Do you agree with the proposed changes?
>>
>>    
>>
>
>Actually, upon further reflection, no, I don't. It seems that somehow
>you're missing something major in how the Makefiles work. When building
>regularly, by issuing just 'make', the Makefiles never touch the chroot
>targets included in the packages Makefiles. Those are only there for
>when you want to build a package separately, ie, for debugging and
>testing purposes.
>  
>
I understand this. There is a command:

chroot "$(MP)" $(chenv-pre-bash) 'set +h && \
         chown -R 0:0 $(WD) $(SRC) $(ROOT) && \
         cd $(ROOT) && make cross-pre-bash $(chbash-pre-bash)'

It runs the whole pre-bash build in one chroot. It uses ch-* targets and 
doesn't use *-only-ch.

>For example, you hit an error on a certain package and you want to
>figure out why it's failing. You can run 'make packagename-only-ch' and
>it will use the chroot target within the sub-package Makefile and call
>itself again once it has chrooted. Look at it a bit more closely -
>you'll get it. :)
>  
>
Yes, and that's what I don't like. Suppose that you want to rebuild only 
libidn. You run "make libidn-only-ch". This calls "mage -C $(PKG)/libidn 
chroot", this results in "make ch-libidn" with the right chroot environment.

But I want to call something different instead of the regular chroot 
command: "qemu-system-x86_64 -user-net -hda /dev/zero -kernel 
/path/to/cross-compiled-kernel -append "root=/dev/nfs nfsroot=..... 
init=$(ROOT)/scripts/init-pkg PACKAGE=libidn" which results in "make 
ch-libidn" inside qemu with the right environment (including distcc 
pointing to the cross-compiler on the host), and that qemu command is in 
fact subject to further changes. So it is a good idea to centralize this.

Also please count the packahes that call the wrong target in their 
chroot command.

I propose to do this by reorganizing the way the "*-only-ch" targets are 
handled. Instead of calling the package-specific "chroot" target in the 
individual Makefile, a common "chroot" target is called. This way, all 
"stage2" targets get a common environment. According to my plan, it's 
now their responsibility (and not the "chroot" target responsibility) to 
adjust it (i.e., append /tools/bin to the $PATH) while calling 
"compile-stage2".

As for the regular way of building packages sequentially, this 
chroot/qemu duality is probably going to be handled by introducing 
metapackages, so that the command cited above becomes:

make cross-pre-bash-only-ch

This is not going to trunk, in any case ;)

-- 
Alexander E. Patrakov



More information about the livecd mailing list