On Dec 6, 2014, at 8:57, Ian Lepore <i...@freebsd.org> wrote: > On Sat, 2014-12-06 at 16:01 +0100, Dimitry Andric wrote: >> [trimmed CC list to -current] >> >> On 06 Dec 2014, at 04:59, Garrett Cooper <yaneurab...@gmail.com> wrote: >>> On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote: >>> >>>> See <https://jenkins.freebsd.org/job/Build-UFS-image/599/> >>> >>> I´m not entirely sure why the "could not determine COMPILER_TYPE" error >>> popped up, but I have a couple of questions/concerns related to the >>> makefile snippet. >>> 1. Does it make sense to check CC when running make install? >> >> Yes, of course it makes sense, if parts of the install depend on e.g. >> COMPILER_TYPE. In some cases, you will have to run ${CC} to determine >> what it is, specifically if it is just "cc”.
Let me phrase it differently… do I need to run cc —version if I’m just going to
be running xinstall to install a bunch of binaries? Seems like a serious waste
of cycles to me.
>>> 2. Why isn´t this value determined once in Makefile.inc1 (per build
>>> phase), then passed down from there
>>
>> Because you are supposed to be able to build stuff in a subdirectory,
>> without invoking the full top-level Makefile infrastructure. The actual
>> infrastructure is in share/mk/bsd.*.mk, in fact.
Let me rephrase this as well: why isn’t the value cached once at the top-level
in a more intelligent way and passed down to bsd.compiler.mk? It was always
calculating ${CC} —version on my branch for instance, until I made this commit:
https://svnweb.freebsd.org/base/projects/building-blocks/share/mk/bsd.compiler.mk?r1=275556&r2=275558
(which I’m going to merge back to head right now because it’s an unnecessary
fork/popen/whatever’s involved to get the value of a throwaway variable).
>>> (I´ve already considered the scenario where someone explicitly sets CC in a
>>> non-toplevel Makefile, which is a problem, but an outlier rather than the
>>> norm)? AFAICT, it gets recomputed for every recursive make, which
>>> contributes to useless forking for something that honestly doesn´t change
>>> all that often/at all.
>>
>> This is indeed a pity, and if you know a better solution, let's hear it,
>> please. :-)
From my perspective, the only place it makes sense for CC to change it during
cross-tools based on Makefile.inc1. Before that it should be value V.X, and
before that it should be value Y.Z, where V.X and Y.Z should be the same. So,
the value should be calculated once in the necessary sections, then passed down
appropriately.
>>> At EMC/Isilon at least, we set CC/CXX=false when running make
>>> distribute*/installkernel/installworld to catch logic errors with
>>> rebuilding code. Should this be in FreeBSD?
>>
>> Not sure what that is meant to achieve. If parts of the installation
>> depend on the value of CC, why would you want to set it to false? Just
>> so it can error out at those points?
>
> I suspect it's to prevent building during the install phase, because
> doing so is astonishing. I was astonished the other day when it
> happened. I would be much happier if it had just errored out.
Yes. If dependencies changed, logically they shouldn’t be recompiled in the
install phase. This could cause additional unexpected/weird issues if say you
updated libc, it recompiled the shared library, but not the static library, and
then stuff blew up later on. That’s one thing Isilon was trying to avoid
because it reveals either bugs in the build process, or bugs in the build
environment, and it could result in weirdness with produced binaries later on
(especially if compat layers change, linked libraries change, etc).
Thanks!
signature.asc
Description: Message signed with OpenPGP using GPGMail
