On Sunday, March 2nd, 2025 at 02:13, Ben Boeckel via Gcc <gcc@gcc.gnu.org> wrote:
> On Sat, Mar 01, 2025 at 16:15:12 +0000, vspefs wrote: > > > 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. > > > It was unmaintained for years, but Zack Weinberg took up maintenance in > 2020. See these articles: > > https://www.owlfolio.org/development/autoconf-swot/ > https://lwn.net/Articles/834682/ > > AFAICT, it's in good hands. Good to hear! > > So if Autotools is having release struggles, I would personally prior to > > solutions that require less effort on the build system side. > > > I think the 9-year gap is "done", but yes, there needs to be substantial > work for automake to support C++ modules properly. I have no idea who > might be interested in funding that (Red Hat for GCC dogfooding of C++ > modules perhaps?) nevermind doing the necessary work. Supporting C++ modules is easy, but I don't think "properly" is possible for any build system under current circumstances. Industrial consensus needed for many subjects: For example, the "permission to import" thing of module is also a general distribution issue. We are still not clear about how we should distribute modules, with questions like: 1. Is there a system-wide, universal way of finding installed modules? 2. How much information should we expose when distributing a module? In what way? GCC and clang both have a .module.json file installed under /lib path, which kind of attempt to answer the first question, and reply the second question with "look, here we try to have a structured description of distributed modules". They're obviously very early, immature, and underdeveloped attempts that aren't designed to solve this problem anyway. But a well-designed "structured description of distributed modules" can solve a lot of problems. However, the question could grow bigger when you throw in more ideas like versioning. We don't necessarily need to have the answers standardized, but some form of consensus needs to exist. Another example is the "multiple CMIs" question. From one aspect, if C++ standard could officially define/validate/standardize compile options, it would be much easier to have a making-everyone-happy answer to this. (although it's simply offloading the annoying-everyone part to the committee) I know some SG15 attempts (like P3335), but you never know standardization. I made this RFC to see if we can have a usable `-Mmodules` output now, and if we can design it so well that it could be trivially useful when build systems implement module-supported Makefile generation. Also to see where we should draw the line between "build system scope" and "compiler scope". > > 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. > > > It's not a significant problem on the build graph side. I only > implemented single-command CMI-and-object rules so far because: > > - it's what Fortran does today and is already supported > - is supported by the three major C++ compilers for C++ I'll have to learn the Fortran practices soon. > Clang does support separate `.cc -> .pcm` and `.pcm -> .o` commands, > > but, IIRC, this is not actually equivalent to `.cc -> {.pcm, .o}` in > > that the codegen may differ subtle ways that may matter. I'm interested > in correctness before we start really squeezing performance out of the > setup, so I'd like to avoid adding more bumpy roads along the way before > we have a smoothed out path to compare it against if/when bugs crop up. I totally agree. My opinion is that it's easier to change compiler implementations/behaviours than established building practices, so we must try to make sure we get the latter right.
