FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=main 2015-06-16T20:58:33Z 2015-06-16T20:58:33Z Warner Losh imp@FreeBSD.org 2015-06-16T20:58:33Z urn:sha1:32c88b5252b10c809902964bd981f04e0c9883fa really need it can find it in the devel/fmake port or pkg install fmake. Note: This commit is orthogonal to the question 'can we fmake buildworld'. Differential Revision: https://reviews.freebsd.org/D2840 2015-01-16T21:39:08Z Will Andrews will@FreeBSD.org 2015-01-16T21:39:08Z urn:sha1:7a37b5fc17b2d3c2f0487756ab32450019fdbd31 Some users build FreeBSD as non-root in Perforce workspaces. By default, Perforce sets files read-only unless they're explicitly being edited. As a result, the -f argument must be used to cp in order to override the read-only flag when copying source files to object directories. Bare use of 'cp' should be avoided in the future. Update all current users of 'cp' in the src tree. Reviewed by: emaste MFC after: 1 week Sponsored by: Spectra Logic 2014-07-23T23:01:54Z Devin Teske dteske@FreeBSD.org 2014-07-23T23:01:54Z urn:sha1:be44449f2d0fa7273b43e6456bc7eb3ba08f1ff4 make.1). Introduced initially via SVN r250699 (sjg). Reviewed by: sjg, gjb MFC after: 3 days X-MFC-to: stable/10 2014-05-14T18:43:13Z Julio Merino jmmv@FreeBSD.org 2014-05-14T18:43:13Z urn:sha1:5ae59dec60e3815b621ae87f74a377cf3449ca55 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. 2014-05-06T04:22:37Z Warner Losh imp@FreeBSD.org 2014-05-06T04:22:37Z urn:sha1:d03127447df90011be0609d292a50a6a17dd2aa1 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). 2014-05-06T04:22:01Z Warner Losh imp@FreeBSD.org 2014-05-06T04:22:01Z urn:sha1:c6063d0da8e1f8d8452b0c2ee1c7ad718c1a7052 from the latter. 2014-03-19T12:29:20Z Julio Merino jmmv@FreeBSD.org 2014-03-19T12:29:20Z urn:sha1:d525bcd959742df2fe7f3dbcd251284537121190 Note that these tests are for fmake, not bmake, and thus they are not installed nor run when bmake is selected (the default). Yes, I have wasted a *ton* of time on moving tests for no real reason other than ensuring they are not left behind. But maybe, just maybe, it was not work in vain: the majority of these tests also work with bmake and the few that don't may point at broken stuff. For example, the tests for the "archive" feature do not work with bmake, but bmake's manpage and source tree seem to imply that they should. So... to be investigated later; need to poke sjg@. 2013-05-16T21:26:46Z Simon J. Gerraty sjg@FreeBSD.org 2013-05-16T21:26:46Z urn:sha1:4c67ba2c7bb3c38f11bed3777735a3adc34df04c MK_BMAKE not being defined. 2013-05-16T15:28:38Z Simon J. Gerraty sjg@FreeBSD.org 2013-05-16T15:28:38Z urn:sha1:3ddfb24d3a17274bb13aa1688eca54fbe2c8aa0f If someone explicitly builds usr.bin/make while MK_BMAKE==yes, install it as 'fmake'. Reviewed by: brooks 2012-06-20T00:37:00Z David E. O'Brien obrien@FreeBSD.org 2012-06-20T00:37:00Z urn:sha1:83b322edc6684abe02f4e442ba748c6cb39aad36