On 2019-03-28 12:11 -0500, Bruce Dubbs via lfs-dev wrote: > On 3/28/19 12:45 AM, Xi Ruoyao via lfs-dev wrote: > > On 2019-03-28 15:15 +1000, James B via lfs-dev wrote: > > > On Wed, 27 Mar 2019 21:59:38 -0500 > > > Bruce Dubbs via lfs-dev <[email protected]> wrote: > > > > > > > There are just too many problems with meson-0.50.0. Therefore I have > > > > reverted to meson-0.49.2 in lfs-svn until it gets fixed. > > > > > > What I don't understand is the mass exodus from a proven tools like > > > autotools > > > (or cmake) to an immature, incomplete, and dependent-laden tools like > > > meson, > > > to build critical system components :( > > > > I don't think autotools are proven - I remember many notes about test > > failures > > in autoconf and automake in LFS book. There are much more XFAILS. > > > > The worst thing in autotools is the stupid libtool with a lot of .la files. > > I agree with that. autotools was created for packages that want to be > available for many versions if Unix (solaris, hp-ux, etc) as well as > Linux. cmake and meson generally are targeted more specifically at > Linux where .la files are not needed.
More annoying thing, several packages still use libltdl so we can't just "find -name \*.la -delete". > > For cmake, I always find it difficult to use. There is not even a > > consistent > > way to specify the library install directory. Personally I classify cmake > > as an > > example of "programs which are hard to integrate into the system, coming > > from > > the mathematical guys". These math guys just throw each package into a > > designated prefix, pullate environments like $PATH and $LD_LIBRARY_PATH > > (yes, > > many guys in my lab don't even know ld.so.conf) and they believe everyone > > will > > do that. When I build packages outside LFS/BLFS but with only cmake > > building > > system avaliable, I just feel headache and want to say colorful metaphors. > > I don't have a lot of problems with cmake any more. Generally when > checking a package using cmake I do: > > mkdir build > cd build > cmake -L .. > > that usually lists all the options a package understands and what > dependencies it finds. It's not always perfect, but usually is enough > to do what is needed. I remember one BLFS package (can't remember which one) hard-coded "PREFIX/lib" in several CMakeLists.txt files. I tried to make up a sed but failed. So at last I have to manually edit all CMakeLists.txt files with vim. And when I was a newbie I believed "-DCMAKE_INSTALL_LIBDIR" would always work (like --libdir in autotools & meson). At last my /usr/lib became a mix up of 32-bit and 64-bit libraries :(. So, now I always recheck packages with cmake by DESTDIR installation before really installing it. -- 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
