Okay, so you want to compile the OS yourself.
You do a git-clone, and create some local branches. One for 12.3, one for 13.1, one for 13-stable, maybe one for current too. Then you git-switch to one of them, and run the
Then you do a git-switch to another branch, and build for some other target. All fine, so far.
Then, some security fixes wash ashore. So you do a git-pull, and then start over. Switch to some branch, and now bring back the respective /usr/obj tree from earlier, kldload the filemon, and enable
Why? Because git-switch modifies the worktree to reflect the required branch. And so it has to write to the files that are different. And so these files get their mtime updated to NOW. And git-switch does absolutely nothing to remedy the mess. And so
Now, I think this is a common and absolutely normal use-case. So other people should already have run into that, and there should be some switch to fix it. But there isn't. Instead, there are discussions that tell us that Linus says this is the required and necessary behaviour, in order to support
Sorry, did I miss something, or have I got lost in a madhouse? And, who is Linus?
Okay, there is also some workaround scripts at that location, to properly restore the mtime. And some of them claim they are really fast, and take only 8 seconds even for "big" repositories like bash or git. I tried them, they take 4 to 20 hours on the FreeBSD src. And they are buggy.
The issue is already some 15 years old, and it happens to appear again and again every couple of years. Obviousely, as there is no proper solution. But apparently there was never somebody with a real need, with an actually bigger repo, and a release branch scheme that would urge frequent branch switching as the most viable approach. Somebody who would get appropriately angry (but I doubt even that would help).
So I finally sat down and crafted something that currently looks like a working solution. It took more than a day and met a lot of unpleasentness. And I continue to wonder why it is always me who happens to stroll into the scene some ten years late, only to find that the state of affairs is, hm, let's say suboptimal...
You do a git-clone, and create some local branches. One for 12.3, one for 13.1, one for 13-stable, maybe one for current too. Then you git-switch to one of them, and run the
make buildworld && make buildkernel. You grab the /usr/src and /usr/obj trees, copy them to the target system, and install as usual via make installworld etc.etc.Then you do a git-switch to another branch, and build for some other target. All fine, so far.
Then, some security fixes wash ashore. So you do a git-pull, and then start over. Switch to some branch, and now bring back the respective /usr/obj tree from earlier, kldload the filemon, and enable
WITH_META_MODE. And this should now go a lot faster and only compile the new changes. But it doesn't. Why? Because git-switch modifies the worktree to reflect the required branch. And so it has to write to the files that are different. And so these files get their mtime updated to NOW. And git-switch does absolutely nothing to remedy the mess. And so
make sees these files as newly modified, and rebuilds practically everything.Now, I think this is a common and absolutely normal use-case. So other people should already have run into that, and there should be some switch to fix it. But there isn't. Instead, there are discussions that tell us that Linus says this is the required and necessary behaviour, in order to support
make correctly! https://stackoverflow.com/a/1964508Sorry, did I miss something, or have I got lost in a madhouse? And, who is Linus?
Okay, there is also some workaround scripts at that location, to properly restore the mtime. And some of them claim they are really fast, and take only 8 seconds even for "big" repositories like bash or git. I tried them, they take 4 to 20 hours on the FreeBSD src. And they are buggy.
The issue is already some 15 years old, and it happens to appear again and again every couple of years. Obviousely, as there is no proper solution. But apparently there was never somebody with a real need, with an actually bigger repo, and a release branch scheme that would urge frequent branch switching as the most viable approach. Somebody who would get appropriately angry (but I doubt even that would help).
So I finally sat down and crafted something that currently looks like a working solution. It took more than a day and met a lot of unpleasentness. And I continue to wonder why it is always me who happens to stroll into the scene some ten years late, only to find that the state of affairs is, hm, let's say suboptimal...
