Re: Build failed in Jenkins: Build-UFS-image #599

On Dec 6, 2014, at 8:57, Ian Lepore <ian_at_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 <yaneurabeya_at_gmail.com> wrote:
>>> On Dec 5, 2014, at 16:52, jenkins-admin_at_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!