1999-11-14 13:54:44 +00:00
|
|
|
# $FreeBSD$
|
|
|
|
|
|
2014-05-06 04:22:01 +00:00
|
|
|
.include <src.opts.mk>
|
2006-03-17 18:54:44 +00:00
|
|
|
|
2018-03-01 19:50:55 +00:00
|
|
|
# For amd64 we have to build 32 and 64 bit versions of things. For
|
|
|
|
|
# others we don't. LIB32LIST is a list of libraries, which if
|
|
|
|
|
# included, need to be built 32-bit as well.
|
|
|
|
|
.if ${MACHINE_ARCH} == "amd64"
|
2021-01-01 06:22:48 +00:00
|
|
|
LIB32LIST=libsa
|
|
|
|
|
.if ${MK_FORTH} != "no"
|
|
|
|
|
LIB32LIST+= ficl
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LOADER_LUA} != "no"
|
|
|
|
|
LIB32LIST+= liblua
|
|
|
|
|
.endif
|
Add Lua as a scripting langauge to /boot/loader
liblua glues the lua run time into the boot loader. It implements all
the runtime routines that lua expects. In addition, it has a few
standard 'C' headers that nueter various aspects of the LUA build that
are too specific to lua to be in libsa. Many refinements from the
original code to improve implementation and the number of included lua
libraries. Use int64_t for lua_Number. Have "/boot/lua" be the default
module path. Numerous cleanups from the original GSoC project,
including hacking libsa to allow lua to be built with only one change
outside luaconf.h.
Add the final bit of lua glue to bring in liblua and plug into the
multiple interpreter framework, previously committed.
Add LOADER_LUA option, currently off by default.
Presently, this is an experimental option. One must opt-in to using
this by defining WITH_LOADER_LUA and WITHOUT_FORTH. It's been
lightly tested, so keep a backup copy of your old loader handy.
The menu code, coming in the next commit, hasn't been exhaustively
tested. A LUA boot loader is 60k larger than a FORTH one, which is
80k larger than a no-interpreter one. Subtle changes in size
may tip things past some subtle limit (the binary is ~430k now
when built with LUA). A future version may offer coexistance.
Bump FreeBSD version to 1200058 to mark the milestone.
Pedro Souza's 2014 Summer of Code project. Rui Paulo, Pedro Arthur,
Zakary Nafziger and Wojciech A. Koszek also contributed. Warner Losh
reworked it extensively into its current form.
Obtained from: https://wiki.freebsd.org/SummerOfCode2014/LuaLoader
Sponsored by: Google Summer of Code
Relnotes: Yes
MFC After: 1 month
Differential Review: https://reviews.freebsd.org/D14295
2018-02-12 15:31:53 +00:00
|
|
|
.endif
|
1998-11-03 06:11:35 +00:00
|
|
|
|
2018-03-01 19:50:55 +00:00
|
|
|
S.yes+= libsa
|
|
|
|
|
|
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
|
|
|
S.${MK_LOADER_OFW}+= libofw
|
|
|
|
|
S.${MK_FDT}+= fdt
|
|
|
|
|
|
2018-03-01 19:50:55 +00:00
|
|
|
S.${MK_FORTH}+= ficl
|
|
|
|
|
S.${MK_FORTH}+= forth
|
|
|
|
|
S.${MK_LOADER_LUA}+= liblua
|
|
|
|
|
S.${MK_LOADER_LUA}+= lua
|
|
|
|
|
S.yes+= defaults
|
2020-12-21 05:31:16 +00:00
|
|
|
S.yes+= fonts
|
|
|
|
|
S.yes+= images
|
2018-03-01 19:50:55 +00:00
|
|
|
S.yes+= man
|
|
|
|
|
|
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
|
|
|
.if ${MK_FORTH} != "no"
|
|
|
|
|
INTERP_DEPENDS+= forth
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LOADER_LUA} != "no"
|
|
|
|
|
INTERP_DEPENDS+= lua
|
|
|
|
|
.endif
|
|
|
|
|
|
2015-03-29 15:43:24 +00:00
|
|
|
.include <bsd.arch.inc.mk>
|
|
|
|
|
|
2018-03-01 19:50:55 +00:00
|
|
|
S.${MK_EFI}+= efi
|
|
|
|
|
S.${MK_LOADER_UBOOT}+= uboot
|
2018-02-27 17:35:29 +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
|
|
|
.if defined(LIB32LIST)
|
|
|
|
|
LIB32DEPENDS= ${LIB32LIST:S/$/32/}
|
|
|
|
|
.endif
|
|
|
|
|
|
2017-11-06 15:22:11 +00:00
|
|
|
.if exists(${.CURDIR}/${MACHINE}/.)
|
2018-03-01 19:50:55 +00:00
|
|
|
S.yes+= ${MACHINE}
|
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_${MACHINE}+= ${INTERP_DEPENDS}
|
|
|
|
|
.if ${MK_FDT} != "no"
|
|
|
|
|
SUBDIR_DEPEND_${MACHINE}+= fdt
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LOADER_UBOOT} != "no"
|
|
|
|
|
SUBDIR_DEPEND_${MACHINE}+= uboot
|
|
|
|
|
.endif
|
|
|
|
|
.if ${MK_LOADER_OFW} != "no"
|
|
|
|
|
SUBDIR_DEPEND_${MACHINE}+= libofw
|
|
|
|
|
.endif
|
2018-03-01 19:50:55 +00:00
|
|
|
.endif
|
|
|
|
|
|
|
|
|
|
# Build the actual subdir list from S.yes, adding in the 32-bit
|
|
|
|
|
# variant if necessary.
|
|
|
|
|
.for _x in ${S.yes}
|
|
|
|
|
SUBDIR+=${_x}
|
|
|
|
|
.if defined(LIB32LIST) && ${LIB32LIST:M${_x}}
|
|
|
|
|
SUBDIR+=${_x}32
|
2008-07-23 07:23:33 +00:00
|
|
|
.endif
|
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
|
|
|
.if ${_x} != "libsa"
|
|
|
|
|
SUBDIR_DEPEND_${_x}+= libsa
|
|
|
|
|
SUBDIR_DEPEND_${_x}32+= libsa32
|
|
|
|
|
.endif
|
2018-03-01 19:50:55 +00:00
|
|
|
.endfor
|
1998-08-21 03:17:42 +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
|
|
|
# Remaining dependencies
|
|
|
|
|
SUBDIR_DEPEND_libsa32+= libsa
|
|
|
|
|
|
|
|
|
|
SUBDIR_DEPEND_forth+= ficl
|
|
|
|
|
SUBDIR_DEPEND_lua+= liblua
|
|
|
|
|
|
|
|
|
|
SUBDIR_DEPEND_efi+= fdt
|
|
|
|
|
|
|
|
|
|
SUBDIR_PARALLEL= yes
|
|
|
|
|
|
1998-08-21 03:17:42 +00:00
|
|
|
.include <bsd.subdir.mk>
|
