Date: Thu, 30 Jun 2022 03:50:50 +0000 From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 264949] lang/gcc11: Needs build time warning for /tmp consumption Message-ID: <bug-264949-29464-6yYg3ukgyA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-264949-29464@https.bugs.freebsd.org/bugzilla/> References: <bug-264949-29464@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264949 --- Comment #14 from Mark Millard <marklmi26-fbsd@yahoo.com> --- (In reply to Lorenzo Salvadore from comment #13) The point of the defaults is only for the FreeBSD build server activity and, so just those machines. I'd expect the defaults to be tailored to work only for that context. Setting defaults otherwise involves too many unknowns, too many conflicting goals, too wide a variety of machines, etc. for the build server activity to be readily/well managed as well. A means of control (OPTIONS) has been given. (One can also work in a way that one varies the Makefiles themselves.) Yes, it does mean that understanding what to do to do ones own builds involves more that if someone had already done the tailoring based something that one just happens to find fits ones desires for doing builds of parts. (I actually experimented with "bulk -a -c" to learn enough to not have to worry much about having builds fail for resource limitations, spanning 8 GiByte RPI4B's through a 1st generation ThreadRipper 1950X as builders. On very rare occasion I start a "bulk -a -c" test in one of the contexts to see if I should adjust things. That is not the only type of rare test.) Measuring and comparing the time of individual builds that are built via parallel builders, each allowed to have parallel processes involved, is very problematical. The easier you make that individual comparisons, the more likely you are causing significant, extra idle "freebsd cpu" time. The more time spent making some progress on something whenever something could be worked on, the harder it is to compare individual times in a useful way. (Personally, I use criteria that lead to high load averages compared to the "freebsd cpu" count involved most of the time. This makes individual comparisons very messy. But "bulk -a -c" total time is still very useful. Smaller but specific subsets can also serve. The official servers are biased differently for how they are handled.) https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage can be used to look at on-going and past production of packages from ports. (It is just a place to find other pages about specific builds and see some summary information.) This is not an appropriate place to go into detail. But a recent "bulk -a -c" sort of run for main targeting amd64 is visible via: http://beefy18.nyi.freebsd.org/build.html?mastername=3Dmain-amd64-default&b= uild=3Dpb790baec9029_s70b5d8fa0f I got to it via starting from https://pkg-status.freebsd.org/?all=3D1&type=3Dpackage . --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264949-29464-6yYg3ukgyA>