On 2012-11-29 23:06, Rob T wrote:
For the moment, let's talk about ddoc, or unit testing in D. That's the
difference, it's not an external tool set, it's instead a a part of the
standard language feature set. BTW, IMO ddoc was implemented poorly,
using comments, which I fully agree with you would be a vary bad way to
go about implementing the feature. In that case, I would rather use Ruby.
The built-in support for unit testing is too simplistic. I think one
needs an external tool anyway that makes use of the built-in support
unit tests.
I just want to be able to do something like:
$ test a.d b.d
And it will run all unit tests in the modules "a" and "b". In D I need
to manually creating a test module which imports all modules I want to
test. This will give the most basic functionality. This is a few things
of that's missing:
* Run a single test
* Names or context for the tests
* Nice report of which tests failed
* Continue running other tests if a given test failed
I would say that the build specific code would have to go into the
main.d file, but since libraries do not have a "main" file, the build
process code would have to go into another file, perhaps named
"build.d", that contains the entire build section which the compiler
uses to kick off the build process. The build.d files can be chained so
that multiple related projects can be constructed.
That's the exact same thing as I'm proposing, except it's the compiler
handling it.
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"
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.
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?
--
/Jacob Carlborg
