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
