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.
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.
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>
of FreeBSD's make by setting WITH_BMAKE. The WITH_BMAKE build makes it
easy for people to switch while working out the kinks -- think ports
tree here. The option will be removed in due time.
Submitted by: Simon Gerraty (sjg@juniper.net)
