Errors compiling DSSS

[Rob T]

On Friday, 30 November 2012 at 08:05:25 UTC, Jacob Carlborg wrote:
> That's the exact same thing as I'm proposing, except it's the 
> compiler handling it.

Which would be better because it is integrated and not an 
external tool.

>> In any event, I'd ask how do the current build systems do it? 
>> They read
>> and parse through the source files to learn about dependencies
>
> No, they:
>
> 1. Run "$ dmd -o- -c main.d -deps=deps.txt" which will write 
> out all dependencies of "main.d" to "deps.txt"

Personally, I don't see how that would work using the current 
form of the output. I tried it with Make to figure out 
dependencies and the problem I immediately ran into was that the 
output did not contain full path information for the projects 
modules, and without that information, there was no way to 
combine builds from related project under a separate folder. What 
I find, is that with D, people seem to be building in simple 
ways, everything under one folder. This works perhaps for many 
people, but not for everyone. Currently I want send all build 
output to a separate folder outside my project folder onto a 
separate drive, but I can't do something even that simple. Sure I 
can hack it with perhaps a symbolic, but that's a hack which 
sucks.

> 2. Read the "deps.txt" file and pass all files to dmd
>> OR a programmer specifies all of it manually, which is a 
>> complete nightmare
>> to maintain on large projects.
>
> I completely agree.
>
>> Now, if things were designed correctly, I
>> don't see why a semi-automated build, using internally 
>> specified build
>> options for manual tweaking where needed, cannot be done with 
>> an
>> embedded build system.
>
> If it was designed correctly the compiler would be built as a 
> library. The build tool could the use this library to get all 
> the dependencies of a given source file.

No doubt the compiler should be a library. Why isn't it? If it 
was a library, then perhaps it could use itself in some very 
interesting ways. The compiler should also accept plugins for 
extensibility. I have not looked at the code yet, but I suspect 
what we have under the hood will make me want to cry.

>> Another analogy is to think about languages that have embedded
>> reflection - unfortunately D currently lacks a generalized 
>> solution for
>> reflection, but you can see hints of the potential it offers.
>> Simplifying how builds are performed through "reflection" will 
>> increase
>> productivity, and will potentially offer new ways of solving 
>> old
>> problems well past what was considered possible before.
>
> Do you have any example?

If there's information inside the source, then the compiler could 
use that information during a build. A very simple example of 
this, would be the imports. So instead of manually dumping a deps 
file, and working some build script magic, the compiler could 
have that information available internally, thereby saving the 
programmer from hacking away at an external build script to get 
it. My guess that's the least of the advantages, there's probably 
a lot more that could be done.

To me, building is just an ugly hack and patch process caused by 
a broken system that is unable to build itself. It's a total 
mess. The best place to fix the problem is right at the source.

--rt