Actually you can't do this for D properly without enlisting the
help of the compiler. Scoped import is a very interesting
conditional dependency (it is realized only if the template is
instantiated).
Also, lazy opening of imports is almost guaranteed to have a
huge good impact on build times.
Your reply confirms my worst fear: you're looking at yet
another general build system, of which there are plenty of
carcasses rotting in the drought left and right of highway 101.
This is one of my biggest frustrations with existing "build
systems" - which really are nothing more than glorified "make"s
with some extra syntax and - for the really advanced ones - ways
to help you correctly specify your makefiles by flagging errors
or missing dependencies.
The build system that will be successful for D will cooperate
with the compiler, which will give it fine-grained dependency
information. Haskell does the same with good results.
Andrei
The compiler has a ton of precise information useful for build
tools, IDEs and other kinds of analysis tools (to this day, it
still bugs the crap out of me that Visual Studio has effectively
*two* compilers, one for intellisense and one for the
command-line and they do not share the same build environment or
share the work they do!) Build is more than just producing a
binary - it incorporates validation through testing, packaging
for distribution, deployment and even versioning. I'd like to
unlock the data in our tools and find ways to leverage it to
improve automation and the whole developer workflow. Those ideas
and principles go beyond D and the compiler of course, but we do
have a nice opportunity here because we can work closely with the
compiler authors, rather than having to rely *entirely* on
OS-level process introspection through e.g. detours (which is
still valuable from a pure dependency discovery process of
course.)
If we came out of this project with "tup-for-D" I'd consider that
an abject failure.
