I read a few mails from the autoconf thread. I'll try to read all now. However, a maybe-off-topic-but-could-be-on-topic question: what exactly is the state of Autotools now? The whole Autotools build system seems to be on a very slow release cycle. They seem to lack enough contributors/maintainers as well.
So if Autotools is having release struggles, I would personally prior to solutions that require less effort on the build system side. Also, I forgot to "reply all" on the last mail. Here's the mail that answers some questions from NightStrike: > GCC conjures up both .o file and .gcm file in one invocation when possible, > too. And yes, that can be managed well with grouped target - but a rule with > grouped target must have a recipe, which I think is a little beyond `gcc -M`'s > scope. > > Thanks for bringing up the pattern rule workaround, though. That's something I > didn't know. (I'm not super familiar with Make!) I'll see what can be done. > > But generally, I try to avoid the problem, because a workaround here could be > a trouble elsewhere. And compiling a CMI is relatively fast, so one-or-zero > time of occasionally recompiling a CMI, compared to other problems that need > to be fixed, is tolerable to me. > > Of course, if you have any good idea, please do share it. > > And yes, Fortran module resonates quite a lot with C++ modules. I'll be > reading about it. On Saturday, March 1st, 2025 at 05:18, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote: > On Fri, Feb 28, 2025 at 13:54:45 -0500, Paul Smith wrote: > > > On Fri, 2025-02-28 at 19:26 +0100, Ben Boeckel via Gcc wrote: > > > > > > In POSIX make, including GNU Make, if a command doesn't modify the > > > > modification time of the target then that target is not considered > > > > updated, and other targets which list it as a prerequisite are not > > > > invoked: > > > > > > Hmm. My understanding was that if a recipe is run, its outputs are > > > assumed to have been updated. I forget where I saw that, but it > > > sticks in my mind for some reason. Experimenting with GNU Make indeed > > > does exhibit `restat = 1` behavior out-of-the-box. That's good to > > > know :). I'll update my priors. > > > > There is one issue related to this: I don't know if Ninja addresses > > this or not: maybe this is what people were thinking of? > > > > Because the modification time of the target is not updated, the recipe > > for the the target will always be run (but targets that depend on it > > will not be run). > > > Ah! Yes, that is a difference. Ninja records the "last run" mtime as a > "shadow mtime" for the rule in its `.ninja_log` file. This is the mtime > used when deciding to rerun the rule or not. Another difference is that > this also encodes the command line last used for the output(s), so if > that changes, it is also considered out-of-date. CMake has command > line change detection, but it is much coarser: there's a file with > information about all command lines in a given target and if that file > changes, all commands in the target rerun. > > > This is the best that make can do, because it relies solely on the > > filesystem as its database of "build state" and doesn't preserve any > > build state of its own. Since "two"'s timestamp was not modified make > > has no way to know that its recipe was actually run previously. > > > > If the recipe to build "two" is expensive, it's probably better to just > > bite the bullet and allow "two" to be updated whenever its > > prerequisites change. > > > Yes, this is reminding me of details I had eventually compressed to > "restat behavior isn't supported in make": it works, but is not > useful because it never results in a "do nothing" build. > > > The only way for make to do better would be for it to keep its own > > database of up-to-date notations, alongside or in addition to the > > filesystem's modification time. That would be a major structural > > change, of course. > > > If it does happen, it would be wonderful to reuse `ninja`'s > `.ninja_log` format. That would allow the usage of tools like > `ninjatracing`[1] to get performance graphs of arbitrary `make` builds. > > Note that there is one fairly annoying thing with this in `ninja`: when > using `sudo ninja`, the log file is written using the elevated > permissions which makes further non-`sudo` usages…fail. See this issue: > > https://github.com/ninja-build/ninja/issues/1302 > > --Ben > > [1] https://github.com/nico/ninjatracing
