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
--
http://linuxfromscratch.org/mailman/listinfo/livecd
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
