Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
Only change to bmake is man page - document .OBJDIR target.
We also get latest dirdeps.mk and friends.
> Description of fields to fill in above: 76 columns --|
> PR: If a GNATS PR is affected by the change.
> Differential Revision: https://reviews.freebsd.org/D### (*full* phabric URL needed).
> Submitted by: If someone else sent in the change.
> Reviewed by: If someone else reviewed your modification.
> Approved by: If you needed approval for this commit.
> Obtained from: If the change is from a third party.
> MFC after: N [day[s]|week[s]|month[s]]. Request a reminder email.
> MFH: Ports tree branch name. Request approval for merge.
> Relnotes: Set to 'yes' for mention in release notes.
> Security: Vulnerability reference (one per line) or description.
> Sponsored by: If the change was sponsored by an organization.
> Empty fields above will be automatically removed.
_M contrib/bmake
M contrib/bmake/ChangeLog
M contrib/bmake/Makefile
M contrib/bmake/bmake.1
M contrib/bmake/bmake.cat1
M contrib/bmake/make.1
M contrib/bmake/mk/ChangeLog
M contrib/bmake/mk/dirdeps.mk
M contrib/bmake/mk/gendirdeps.mk
M contrib/bmake/mk/install-mk
M contrib/bmake/mk/meta.stage.mk
M contrib/bmake/mk/meta.sys.mk
M contrib/bmake/mk/mkopt.sh
M contrib/bmake/targ.c
M usr.bin/bmake/Makefile
problem with broken in-tree builds (which are used far more
pervasively than I'd known outside the tree). However, weird results
may now happen if at any point in the tree above you there happens to
be a directory that has subdirectory of share/mk, as unpredictable
results will follow. This was considered the lessor of the two evils,
at least for now. In the future this will be removed again when the
underlying issues are resolved.
in SUBDIRS having tests added to it, which fails. Work around this by
checking to make sure tests exists before adding it to subdirs and
work to get the generated file fixed so we can rename Makefile.inc to
something else so it isn't automatically included by subdirs...
This first step is mostly to prevent the code from rotting even further
and to ensure these do not get wiped when fmake's code is removed from
the tree.
These tests are currently being skipped because they detect the underlying
make is not fmake and thus disable themselves -- and the reason is that
some of the tests fail, possibly due to legitimate bugs. Enabling them to
run against bmake will come separately.
Lastly, it would be ideal if these tests were fed upstream but they are
not ready for that yet. In the interim, just put them under usr.bin/bmake/
while we sort things out. The existence of a different unit-tests directory
within here makes me feel less guilty about this.
Change confirmed working with a clean amd64 build.
instead of from /usr/share/mk.
I'm not sure that this will let buildworld complete on a system with
no installed src.opts.mk (make buildworld is still running), but the
tinderbox builds are all failing earlyon without this patch.
build world, so it is the only make we build or install. fmake is
still in the tree, but disconnected, and upgrades from older systems
that still have bmake has not been removed, but its state has not been
tested (it should work given how minimal the work to upgrade to bmake
is).
make) ended up being built with -DFORCE_MACHINE. This broke the lib32
built for amd64 & powerpc64.
This fix is comes with the next import of bmake, but is committed here
and now to minimize the exposure to the bug.
Submitted by: Simon Gerraty <sjg@juniper.net>
