> On Mar 3, 2026, at 4:22 AM, Warner Losh <[email protected]> wrote: > > On Tue, Mar 3, 2026 at 5:18 AM Brooks Davis <[email protected]> wrote: > On Tue, Mar 03, 2026 at 04:25:48AM -0700, Warner Losh wrote: > > On Mon, Mar 2, 2026, 11:00???PM Enji Cooper <[email protected]> wrote: > > > > > The branch main has been updated by ngie: > > > > > > URL: > > > https://cgit.FreeBSD.org/src/commit/?id=912864912b71951f9a636190b1dba80528f588eb > > > > > > commit 912864912b71951f9a636190b1dba80528f588eb > > > Author: Enji Cooper <[email protected]> > > > AuthorDate: 2026-03-03 05:59:50 +0000 > > > Commit: Enji Cooper <[email protected]> > > > CommitDate: 2026-03-03 05:59:56 +0000 > > > > > > Run `make obj` before running `make test-includes` > > > > > > Before this change, `make test-includes` (run as part of buildworld) > > > would place test files in the current directory, which would clutter > > > up > > > git clones. Run `make obj` beforehand to ensure that the files are put > > > in `${.OBJDIR}` instead of `${.CURDIR}`. This helps cut down on the > > > noise significantly when running commands like `git status`. > > > > > > > I've never seen this happen. .OBJDIR is created automatically for me always > > for the last 5 years... I run buildworld all the time. Can you explain when > > / how it happens more specifically or back out the change? > > The commit message is unintentionally misleading and incomplete. I hit > the problem a week or so ago when fixing gcc12 builds and lacked the > time to follow up. test-includes is fine as part of buildworld, but > when run directly from src does fill tools/build/test-includes with .c > files if you blow away the objdir (which seems to the the only reliably > way to cause test-includes to retest some more complex cases.) > > Ah! That should have been in the commit message as the edge case > that provoked this. That's a decent explanation, though there's other > bits of buildworld that will also cause problems if you do them in isolation > and not part of buildworld. This one, though, is important enough to make > an exception for, I think. It's one that's most likely to be used in > isolation.
Hi Warner, I consistently run into this behavior when doing mfsbsd builds on my 14.3-RELEASE host using this src.conf: https://reviews.freebsd.org/P702 . MK_AUTO_OBJ=yes as shown here: https://reviews.freebsd.org/P703 . I always run this target as part of buildworld on my 14.3-RELEASE host, so whatever is working on your end is likely an artifact of the build host environment, whereas what’s not working for me like you expect is an artifact of my build host environment. This: > Before this change, `make test-includes` (run as part of buildworld) > would place test files in the current directory, which would clutter up > git clones. Could more accurately be expressed like this: > Before this change, `make test-includes` (run as part of buildworld) > would place test files in the current directory on my 14.3-RELEASE > build host, which would clutter up git clones. The exact reason why there’s a difference eludes me right now. -Enji PS I was waiting for a response to the Differential for over a week; I landed the change because I hadn’t received feedback on the review in that period of time and because it gets really old quickly having to always do `git status -uno` in my clones to make sure I’m not accidentally committing things that shouldn’t be committed. This is especially annoying when doing rebases with my “Mac” dev branch because it has a lot of overlapping sections of code in asmc(4) and thunderbolt(4).
signature.asc
Description: Message signed with OpenPGP
