3 ms·

If the compiler and the build system is an integrated product, then right, this shouldn't be too hard. But that's not usually the case. If they're not, what's

If the compiler and the build system is an integrated product, then right, this shouldn't be too hard. But that's not usually the case. If they're not, what's the interface for the initial build step? Is it still something like "gcc -MD"? But "gcc -MD" can't just spit out a list of files. It will have to output not only file names but also module names (both referenced and declared), because resolving module names to file names requires global knowledge. That means every build tool that wants to work with C++ must be changed to take in this extended information and resolve module dependencies. Because otherwise, if there's even a single module in your 1339 file project, then current tooling breaks. Which will put pressure on developers to not add that first module, slowing adoption.

knorker 5y ago
Sure, probably a little bit more work. But I think building a tree of 1339 items is quick enough even on a PDP-11, right? Or is there a step to this I'm missing? Can't they be analyzed individually and then joined? Conceptually this merging isn't much different from the fact that gcc -MD needs to output data formatted in a way that Make understands. But fair enough. I feel like I'm for the second time am saying "just add another stage to the build". Still. "Dead on arrival" is a bit much.
- munch117 5y ago
  Make doesn't understand gcc -MD output. Make has stayed basically the same for half a century. There's nothing language-specific in make. For example, when C++ was invented, nothing needed to be added to make, because the general mechanism could easily support adding a cfront step that compiled .cxx files into .c. It looks like that's changing now. Yesterday's make will not be able to build tomorrow's C++.
  - knorker 5y ago
    > Make doesn't understand gcc -MD output. How do you mean? It's literally Makefile syntax that's being output, and it's directly included by the Makefile as-is.
    - munch117 5y ago
      You're right, that wasn't well phrased. What I meant is that make doesn't have special code to handle "gcc -MD" output. gcc is adapted to the needs of make, not the other way around.
      - knorker 5y ago
        I'm not going to try to design the best way to do the equivalent for C++ modules here in a HN comment, but it doesn't seem like a particularly hard problem. Of course it could be exactly because I've not seriously written a compiler or build system that I mistake the problem for not being hard. But it shouldn't be a problem for explicit dependency build systems like Bazel. And people have written automatic Bazel dependency tooling, so it really looks to me like "what's the best way to do this" rather than "we can't do this", which the article implies. Yes, gcc produces dependency information while compiling, and is adapted for Make. But in theory this could be done by `./configure` or something in a dedicated script. It'd not even be hard. And it's super quick: cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< It's not without precedence to have a pre-stage. Just look at the Ninja build system.
        munch117 5y ago
        > cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< So how would you change that incantation to accommodate C++ with modules? Edited to add: Okay, you did say "I'm not going to try to design the best way to do the equivalent for C++ modules here in a HN comment", but then all you've shown is that it's easy to implement for C++ without modules.
        knorker 5y ago
        What I meant with that oneliner was to show that you don't even need compiler integration. A much simpler tool (in this case the preprocessor) could extract just the needed parts without parsing the rest. Sure, it's harder to tokenize C++, but once you have the yacc for it it's pretty simple to get a list of provided and needed modules, right? We have pretty advanced tools nowadays even for rewriting source code. The Go standard library has a package for parsing a Go file. You can use that and easily extract the import list and package name definition. I don't see (perhaps due to my ignorance of C++ module details) why this doesn't translate. Yes, Go's compiler is integrated with its build system. But I'm saying that's not a prerequisite. I'm saying extracting the necessary information from a C++ file is quick and easy. What I'm not trying to do is design build system and compiler passes. Am I missing something? Is it inherently not possible to create a tool that will take C++ source code and output its imports and exports, or that it's even hard? (again, aside from writing the YACC correctly, once. But the complexity of C++ is mostly not its tokenization)

knorker 5y ago

Sure, probably a little bit more work. But I think building a tree of 1339 items is quick enough even on a PDP-11, right? Or is there a step to this I'm missing? Can't they be analyzed individually and then joined? Conceptually this merging isn't much different from the fact that gcc -MD needs to output data formatted in a way that Make understands. But fair enough. I feel like I'm for the second time am saying "just add another stage to the build". Still. "Dead on arrival" is a bit much.

munch117 5y ago
Make doesn't understand gcc -MD output. Make has stayed basically the same for half a century. There's nothing language-specific in make. For example, when C++ was invented, nothing needed to be added to make, because the general mechanism could easily support adding a cfront step that compiled .cxx files into .c. It looks like that's changing now. Yesterday's make will not be able to build tomorrow's C++.
- knorker 5y ago
  > Make doesn't understand gcc -MD output. How do you mean? It's literally Makefile syntax that's being output, and it's directly included by the Makefile as-is.
  - munch117 5y ago
    You're right, that wasn't well phrased. What I meant is that make doesn't have special code to handle "gcc -MD" output. gcc is adapted to the needs of make, not the other way around.
    - knorker 5y ago
      I'm not going to try to design the best way to do the equivalent for C++ modules here in a HN comment, but it doesn't seem like a particularly hard problem. Of course it could be exactly because I've not seriously written a compiler or build system that I mistake the problem for not being hard. But it shouldn't be a problem for explicit dependency build systems like Bazel. And people have written automatic Bazel dependency tooling, so it really looks to me like "what's the best way to do this" rather than "we can't do this", which the article implies. Yes, gcc produces dependency information while compiling, and is adapted for Make. But in theory this could be done by `./configure` or something in a dedicated script. It'd not even be hard. And it's super quick: cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< It's not without precedence to have a pre-stage. Just look at the Ninja build system.
      - munch117 5y ago
        > cpp -I. src/foo.cc | grep '^# ' | sed 's/^[^"]"//;s/"[^"]$//' | sort | uniq | grep -v \< So how would you change that incantation to accommodate C++ with modules? Edited to add: Okay, you did say "I'm not going to try to design the best way to do the equivalent for C++ modules here in a HN comment", but then all you've shown is that it's easy to implement for C++ without modules.
        knorker 5y ago
        What I meant with that oneliner was to show that you don't even need compiler integration. A much simpler tool (in this case the preprocessor) could extract just the needed parts without parsing the rest. Sure, it's harder to tokenize C++, but once you have the yacc for it it's pretty simple to get a list of provided and needed modules, right? We have pretty advanced tools nowadays even for rewriting source code. The Go standard library has a package for parsing a Go file. You can use that and easily extract the import list and package name definition. I don't see (perhaps due to my ignorance of C++ module details) why this doesn't translate. Yes, Go's compiler is integrated with its build system. But I'm saying that's not a prerequisite. I'm saying extracting the necessary information from a C++ file is quick and easy. What I'm not trying to do is design build system and compiler passes. Am I missing something? Is it inherently not possible to create a tool that will take C++ source code and output its imports and exports, or that it's even hard? (again, aside from writing the YACC correctly, once. But the complexity of C++ is mostly not its tokenization)