On 2019-03-28 16:35 +1000, James B wrote: > On Thu, 28 Mar 2019 13:45:56 +0800 > Xi Ruoyao via lfs-dev <[email protected]> wrote: > > > > Just my 2 cents. > > > > Also, just my 0.01 yuan (about 1/7 cents :). > > LOL. I certainly agree with you that autotools and cmake aren't without > problems. Autotools is definitely a nightmare to debug, and newer versions may > not even be backward compatible. I also agree that libtool is annoying - many > build breakage can be traced to it. > > But the point is that meson isn't any better, it lacks maturity (again, newer > version isn't backward compatible either), lacks features ... so why change > from one broken tools to another; and why the rush to embrace it, breaking > builds left and right while doing so. > > And then Python (which meson depends on) isn't exactly straightforward to > bootstrap, and doubly so for multilib environments.
I build GCC with "--enable-multiarch" so Python 3 will use suffixes "x86_64- linux-gnu" and "i386-linux-gnu" to distinguish 64-bit and 32-bit loadable shared objects. Note that this option do _not_ make GCC use Debian multiarch directory layout - to customize a multilib directory layout we have to edit t-linux64 manually. I've not read Thomas' mutlilib book to see how he handles this. > Anyway. Here in LFS we don't get to make that decisions, we just have to live > with whatever upstream packages have decided. Yes. Dependency is such a complex problem so the build tools handling them have problems here or there. Oh, this reminds me in (B)LFS book a lot of dependency information is not up to date (I am sure because I just updated two of them). Updating the book is what we should actually do :). -- Xi Ruoyao <[email protected]> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
