On Tue, Mar 3, 2026 at 11:17 AM Enji Cooper (yaneurabeya) < [email protected]> wrote:
> > > 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. > The likely reason is that you explicitly ran `make test-includes` without first running `buildworld` to create the objdir. As part of buildworld, it always creates the right thing. Or there's some other partial evaluation. That's the only way I could recreate it, and only if I turned off metamode. 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). Yea, you didn't ping me on it. I've got a lot going on... There's a lot of requests with my name on it and w/o an explicit ping, I can often miss them. It's not wrong, per se, but the commit message was incorrect and overly broad. Brooks showed me a way to recreate it, which I did, but I couldn't otherwise create this with either meta mode on or off. I doubt that cross-version builds would cause it too, but I suppose it might. I do get the annoyance. And it all worked out: I found a way to trigger this, even if it isn't what you are hitting. Warner
