Errors compiling DSSS

Jacob Carlborg doob at me.com
Fri Nov 30 00:05:24 PST 2012


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


More information about the Digitalmars-d mailing list