Page MenuHomeFreeBSD

Allow building world without inheriting $PATH
ClosedPublic

Authored by arichardson on Aug 20 2018, 4:12 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Unknown Object (File)
Sat, Apr 20, 1:04 PM
Subscribers
None

Details

Summary

Allow building world without inheriting $PATH

Inheriting $PATH during the build phase can cause the build to fail when
compiling on a different system due to missing build tools or incompatible
versions somewhere in $PATH. This has cause build failures for us before
due to the jenkins slaves still running FreeBSD 10.
Listing the tools we depend on explicitly instead of just using whatever
happens to be in $PATH allows us to check that we don't accidentally add a
new build dependency.

All tools that do no need to be bootstrapped will now be symlinked to
${WORLDTMP}/legacy/bin and during the build phase $PATH will only contain
${WORLDTMP}. There is also a new variable "BOOTSTRAP_ALL_TOOLS" which can
be set to force compiling almost all bootstrap tools instead of symlinking
them. This will not bootstrap tools such as cp,mv, etc. since they may be
used during the build and for those we should really only be using POSIX
compatible options.

Furthermore, this change is required in order to be able to build on
non-FreeBSD hosts. While the same binaries may exist on Linux/MacOS they
often accept different flags or produce incompatible output.

Test Plan

make tinderbox succeeds

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 20595
Build 20016: arc lint + arc unit

Event Timeline

arichardson edited the test plan for this revision. (Show Details)

added bzip2 to the required bootstrap tools

Just some minor nits. I think sanitizing $PATH to explicitly identify what build tools we need is good, certainly for cross-building from a non-FreeBSD host. This approach also seems to ensure that if we add a new build tool it will break on FreeBSD hosts right away forcing it to be handled (rather than only breaking on non-FreeBSD hosts).

Makefile.inc1
588

s/inhering/inheriting/ (there is an instance of that in the commit message as well)

671

Maybe a newline after this line?

2022

s/link/links/

2028

s/bootstrapping/BOOTSTRAPPING/?

2269

s/builing/building/

arichardson marked 5 inline comments as done.
arichardson edited the summary of this revision. (Show Details)

Fixed typos

moved gzip/bzip to compatible tools (we only compress/decompress files, and this should be compatible across platforms)

Fix build of arm kernels in tinderbox by ensuring that cpp is in $PATH

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

A trivial test case would be nanobsd:

cd tools/tools/nanobsd/embedded ; sh ../nanobsd.sh -c qemu-amd64-uefi.cfg

which uses the feature to build mkimg.

In D16815#358213, @imp wrote:
In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

A trivial test case would be nanobsd:

cd tools/tools/nanobsd/embedded ; sh ../nanobsd.sh -c qemu-amd64-uefi.cfg

which uses the feature to build mkimg.

Thanks, I'll try that and update the patch if necessary.

In D16815#358213, @imp wrote:
In D16815#358208, @imp wrote:

How does this interact with LOCAL_XTOOL_DIRS? Doesn't this totally break that feature?

As far as I can tell LOCAL_XTOOL_DIRS is only added to the cross-tools list of subdirectories so it should just work (unless the build of LOCAL_XTOOL_DIRS depends on another tool that is not in $PATH)

A trivial test case would be nanobsd:

cd tools/tools/nanobsd/embedded ; sh ../nanobsd.sh -c qemu-amd64-uefi.cfg

which uses the feature to build mkimg.

Thanks, I'll try that and update the patch if necessary.

You'll need the fix we talked about elsewhere for sys* vs sys too.

Add unifdef to build tools if MK_AMD!=no
Add the universe toolchain to $PATH

Make nanobsd.sh work without $PATH in $TMPPATH

Makefile.inc1
2212

Picking a random spot to comment...

It looks like we have two lists of things. One with a path, and one without. That seems inefficient. Is there some way we can have only one list?

  • Use some bmake variable modifiers to avoid duplication
  • Fix typos in comments
arichardson marked an inline comment as done.
  • rebased on HEAD
  • fixed an incorrect defined()
arichardson retitled this revision from Allow building world without inhering $PATH to Allow building world without inheriting $PATH.

Fix build of some kernels by adding "stat" to the required tools

Makefile.inc1
584

Can we use the ${} var name instead of tmp/legacy in the comment, in case it changes in the future? Our path names for build tools etc. are somewhat obtuse and I hope we can clean them up in a subsequent commit.

2174

"for by"

Module @emaste's comments on comments, I think this is ready to go.

This revision is now accepted and ready to land.Nov 1 2018, 10:51 PM

Fixed comments.

Unless anyone can see any outstanding issues, I will commit this either later today or tomorrow.

This revision now requires review to proceed.Nov 2 2018, 1:39 PM
This revision was not accepted when it landed; it landed in state Needs Review.Nov 5 2018, 7:51 PM
This revision was automatically updated to reflect the committed changes.
arichardson marked an inline comment as done.