Date: Sun, 10 Mar 2024 15:04:11 -0700 From: Mark Millard <marklmi@yahoo.com> To: Nuno Teixeira <eduardo@freebsd.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: FreeBSD ports community is broken [port building configuration notes] Message-ID: <F32793ED-7580-4D27-8352-A03890CC8437@yahoo.com> In-Reply-To: <CAFDf7UJ9coGqsL8OX0TrigXvM9ZZaHQk-EdeJoWuxk19g%2BvWSg@mail.gmail.com> References: <87B38D6C-1D83-4158-B03B-F4C8EA396DD1@yahoo.com> <C2D38005-534B-44D6-8C1B-88756A946229@yahoo.com> <B623B102-F70D-4FD5-99F3-6E60B9D31187@yahoo.com> <E2CB9BBD-007E-4B97-9711-682571BD5DF0@yahoo.com> <4A386631-E8FF-4640-A927-46DE38F07F00@yahoo.com> <CAFDf7UJ9coGqsL8OX0TrigXvM9ZZaHQk-EdeJoWuxk19g%2BvWSg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 10, 2024, at 13:34, Nuno Teixeira <eduardo@freebsd.org> wrote: >> Hello Mark, Hello. >>> Context: 1GHz, 4 core, cortex-a7 (armv7), 2 GiBytes RAM, USB2. >>> RAM+SWAP: 5.6 GiBytes. Also, this is doing my normal armv7 (and >>> aarch64) style of devel/llvm* build: OPTION'd to BE_NATIVE >>> instead of BE_STANDARD and OPTION'd to not build MLIR. I forgot to mention that my builds on armv7 are set up to use -mcpu=3Dcortex-a7 most everywhere as well, even for building rust. (I'm willing to have some small, local FreeBSD ports infrastructure modifications involved to set such things up.) >> llvm BE_NATIVE/without MLIR seems the best option for this kind of = hardware. >> I will test it right away and compare times. >>=20 >> Related to rust, it have an experimental option to build with port >> llvm instead of bundled. >> Have you test it? No, for a couple of reasons: One is that I tend to build the latest devel/llvm* that is not devel/llvm-devel . (Analogously for lang/gcc* vs. lang/gcc*-devel .) Rust is generally not set up for using that recent of a llvm* as I understand and I've no interest in dealing with incompatibilities showing up. Another is that if devel/llvm* must complete building first, then the over 3 day lang/rust build must start after the over 4 day devel/llvm* build finishes, guaranteeing an elapsed time for the 2 of over a week. Note that in what I did the 4 days for devel/llvm18 covered the whole lang/rust build's time frame as well. (Rust takes less time to build in part due to it builds a smaller subset of llvm than a devel/llvm* does. [Rust uses a lot more temporary disk space than devel/llvm* does.]) In poudriere.conf I also use the likes of: PRIORITY_BOOST=3D"cmake-core llvm18 boost-libs gcc-arm-embedded" Listing rust explicitly would help make sure that the two overlap in time. (Both depend on cmake-core .) (Remember: that I'm partitioning to keep the RAM+SWAP use with signifciant margin while also avoiding FreeBSD reporting potential mistuning of the SWAP size [given the RAM size]. So I avoid letting devel/llvm* have all 4 hardware threads in use for its normal build activities. That might roughtly double the RAM+SWAP peak usage and make failed builds far more likely.) >> Tomorow I will do this builds and share results. >>=20 >> Note: I did not change llvm default options in the past because I was >> concerned about it affects testports. I depend on that I do not use any ports that need MLIR and that I do not build for other machines. (On aarch64 I only build for aarch64 and armv7 --but BE_NATIVE covers allowing that.) >> But, I need to give it a go, because build times are impressive. I'll note that I might be able to do better on the likes of the Rock64 (cortex-a53 aarch64 with armv7 support as well) instead of the Orange Pi+ 2ed (cortex-a7 armv7): aarch64 at a somewhat faster clock rate (but still 4 hardware threads), 4 GiBytes of RAM, aarch64 allows more swap per GiByte of RAM plus there is more RAM in the first place, USB3. So RAM+SWAP =3D=3D 18 GiByte or so (but under 20 GiBytes for sure), if I remember right, could be put to use if it turned out to be handy. An interesting note about this is that it applies to armv7 poudriere jails used on the Rock64 as well: More RAM available overall, potentially avoiding using SWAP space at all (as thigns currently are) for the PARALLEL_JOBS=3D2 and MAKE_JOBS_NUMBER_LIMIT=3D2 combination. (I'm not using MAKE_JOBS_NUMBER directly any more.) One thing coming up is that lang/gcc14 will be a bigger, more time consuming build than lang/gcc13 and the like, because gcc14 needs to use the standard bootstrap instead of avoiding the bootstrap. (Avoiding it leads to build failure for lang/gcc14 . The gcc14+ bootstrap build process after the initial "C++11 is sufficient" stage depends on design choices that are enforced that go beyond what is in the C++11 standard and libc++ does not use those design choices. It gets ever messier to sidestep this. In fact, even language/gcc13 and the like have some sidestepping involved to allow avoiding the bootstrap.) =3D=3D=3D Mark Millard marklmi at yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F32793ED-7580-4D27-8352-A03890CC8437>