1998-10-09 23:30:16 +00:00
|
|
|
|
2018-02-26 03:16:04 +00:00
|
|
|
NO_OBJ=t
|
|
|
|
|
|
2017-11-06 15:22:17 +00:00
|
|
|
.include <bsd.init.mk>
|
2009-12-22 20:56:33 +00:00
|
|
|
|
stand: properly declare subdir deps or .WAIT, do parallel build
buildworld already runs the stand build in parallel[1], so make it easier to
identify ordering issues by properly establishing dependencies or adding
.WAIT where needed.
Everything in stand/ relies on libsa, either directly or indirectly, because
libsa build is where the stand headers get installed and it gets linked in
most places.
Interpreters depend on their libs, machine dirs usually depend on top-level
libs that are getting built and at least one of the interpreter flavors.
For i386, order btx/libi386/libfirewire before everything else using a
big-ol-.WAIT hammer. btx is the most common dependency, but the others are
used sporadically. This seems to be where the race reporting on the mailing
list is- AFAICT, the following sequence is happening:
1.) One of the loaders gets built based on stale btx/btxldr
2.) btx/btxldr gets rebuilt
3.) installworld triggers loader rebuild because btx was rebuilt after
This seems like the most plausible explanation, as they've verified system
time and timestamps.
While we're here, let's switch stand/ over to a completely parallel build so
we can work out these kinds of issues in isolation rather than in the middle
of a larger build.
Reviewed by: bdragon, sjg, tsoome
Tested by: bdragon (-j1024, no failures, significant speed improvement)
Differential Revision: https://reviews.freebsd.org/D23411
2020-12-31 17:15:45 +00:00
|
|
|
# Almost everything else here relies on btxldr, so we must make sure it's built
|
|
|
|
|
# before everything else proceeds so we don't end up building against a stale
|
|
|
|
|
# btxldr and ending up with a build-during-install scenario.
|
|
|
|
|
SUBDIR.yes+= btx libi386
|
|
|
|
|
SUBDIR.yes+= .WAIT
|
|
|
|
|
|
|
|
|
|
SUBDIR.yes+= mbr pmbr boot0 boot0sio boot2 cdboot gptboot \
|
|
|
|
|
isoboot
|
2017-11-10 23:54:41 +00:00
|
|
|
|
2018-08-14 18:44:41 +00:00
|
|
|
SUBDIR.${MK_FORTH}+= loader_4th
|
|
|
|
|
SUBDIR.${MK_LOADER_LUA}+= loader_lua
|
|
|
|
|
SUBDIR.yes+= loader_simp
|
2000-03-28 01:19:53 +00:00
|
|
|
|
|
|
|
|
# special boot programs, 'self-extracting boot2+loader'
|
2018-03-01 21:46:01 +00:00
|
|
|
SUBDIR.yes+= pxeldr
|
1998-10-11 12:59:40 +00:00
|
|
|
|
2019-01-05 22:45:20 +00:00
|
|
|
SUBDIR.${MK_LOADER_ZFS}+= zfsboot gptzfsboot
|
2009-12-22 20:56:33 +00:00
|
|
|
|
stand: properly declare subdir deps or .WAIT, do parallel build
buildworld already runs the stand build in parallel[1], so make it easier to
identify ordering issues by properly establishing dependencies or adding
.WAIT where needed.
Everything in stand/ relies on libsa, either directly or indirectly, because
libsa build is where the stand headers get installed and it gets linked in
most places.
Interpreters depend on their libs, machine dirs usually depend on top-level
libs that are getting built and at least one of the interpreter flavors.
For i386, order btx/libi386/libfirewire before everything else using a
big-ol-.WAIT hammer. btx is the most common dependency, but the others are
used sporadically. This seems to be where the race reporting on the mailing
list is- AFAICT, the following sequence is happening:
1.) One of the loaders gets built based on stale btx/btxldr
2.) btx/btxldr gets rebuilt
3.) installworld triggers loader rebuild because btx was rebuilt after
This seems like the most plausible explanation, as they've verified system
time and timestamps.
While we're here, let's switch stand/ over to a completely parallel build so
we can work out these kinds of issues in isolation rather than in the middle
of a larger build.
Reviewed by: bdragon, sjg, tsoome
Tested by: bdragon (-j1024, no failures, significant speed improvement)
Differential Revision: https://reviews.freebsd.org/D23411
2020-12-31 17:15:45 +00:00
|
|
|
SUBDIR_DEPEND_pxeldr+= loader_${LOADER_DEFAULT_INTERP}
|
|
|
|
|
|
1998-08-21 03:17:42 +00:00
|
|
|
.include <bsd.subdir.mk>
|