Potential of a compiler that creates the executable at once

[rempas]

On Friday, 11 February 2022 at 17:36:03 UTC, Patrick Schluter 
wrote:
>
> If one wants to get really historic it is also what made Turbo 
> Pascal did up to version 3.0. With Turbo Pascal 4.0 they went 
> back to more classic object file/linker and there is a good 
> reason for that. Separate compilation and linking modules and 
> libraries are a thing. If you build the compiler for direct 
> executable production you have to still support normal object 
> file/library handling i.e. you put the functionality of the 
> linker into your compiler.

Yep and that's what I love about it! You can have 2 ways to do 
the same thing and choose based on what's best for the case.

For example, if your projects has 10M LoC, even if you can 
compiler 1M LoC/S (which is a very big number), your project will 
need 10 seconds to build which will make it very annoying. In 
that case, we use the classic method of creating object files to 
the files that were changed and then link them together.

However, if your project is 1M LoC or less, that is less than 1 
second to build it which is not noticeable at all. The same 
happens when the end-user compiles the software from source and 
doesn't care (and won't even keep) about the object files because 
he/she is not a developer. In that case it makes sense to not 
waste time creating the object file and go straight creating the 
executable/library.

If we are to make a new compiler (which I plan to), we should 
create a whole toolchain that will consist of all the tools. 
Sounds complex, I know but what's the point if we don't advance? 
Make another compiler that outputs assembly so it will always 
have dependencies and it will be slow to compile (slow compared 
to if we outputted machine language directly)?