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