Build failed in Jenkins: Build-UFS-image #599
Dimitry Andric
dim at FreeBSD.org
Sat Dec 6 15:01:42 UTC 2014
[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".
> 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.
> (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. :-)
> 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?
-Dimitry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20141206/8d449ea1/attachment.sig>
More information about the freebsd-current
mailing list