Comment by ratmice
6 years ago
I didn't do a good job of explaining it, the thing is that if your compiler is truly pure, your source input is a node in a graph, the compiler is an edge, and the output is another node. Given 2 languages with pure compilers the entire compilation process inherently admits a DAG, rather than having to reconstruct the DAG in order to drive the compilation process.
> I didn't do a good job of explaining it, the thing is that if your compiler is truly pure, your source input is a node in a graph, the compiler is an edge, and the output is another node.
You've just described the role of a compiler in a build system.
> Given 2 languages with pure compilers the entire compilation process inherently admits a DAG
That's what you're getting wrong. Building is not the same thing as compiling. A software build is a workflow comprised of one or more jobs, where compiling is one of the many types of jobs that's performed. In fact, the process of generating a library or executable from source code is a multi-step process where compiling is only one of the many steps. You get a source code, which may be processed by a macro processor to generate the source code to be compiled, then the compiler generates binaries from that source code, which are then handed to the linker, etc etc etc.
What build systems get wrong from a purity perspective is that the compiler has hidden inputs and outputs from the build systems perspective.
You cannot infer from the inputs and outputs the DAG shape. And so you must construct an artificial mapping to those inputs and outputs.
All I am saying is in pure compilers this is unneccesary because inputs and outputs and compilation steps readily form a graph shape.
Its hard just hard to explain because our familiar approach (to operating systems in general) is not well suited to it.
Couple of introspective questions: From a makefile can you reconstruct the input, send it over the network and successfully compile it without knowledge specific to the compilation step?
Can you modify the input in memory, and recompile it without saving?
Can you start the final step when the first step has finished?
All of these things should be realistically possible in a pure build process where each step is pure. Some of these questions relate to the input, some whether the DAG accurately reflects the real DAG underlying the build steps, etc etc etc.
Anyhow I've said all that I really want to say, that our familiar systems don't readily admit it is a separate topic all together.
> What build systems get wrong f
Build systems are not getting anything wrong. You're just struggling with a bunch of misconceptions about what a build system is and does, and what role a compiler plays in the whole process.
> is that the compiler has hidden inputs
There are no hidden inputs. There are only the compiler settings and project configs, and even the choice of compiler, which are all managed and set by the build system, and then there is the source code.
That's it.