Errors compiling DSSS

[Rob T]

On Thursday, 29 November 2012 at 20:47:49 UTC, Jacob Carlborg 
wrote:
> On 2012-11-29 19:53, Rob T wrote:
> Ruby would not be a runtime dependency. It's embedded in the 
> tool just like any other library.

OK, that's better,

> If I recall correctly, you need to use that exact syntax. If 
> you move the first brace to a new line it won't work. That's 
> the problem one get when using custom "languages" for these 
> kind of things.

OK, but the idea is to get rid of DSSS like systems, partly for 
the same sort of reasons.

> What's the difference compared to any other build tool. Where 
> you have to learn some kind of special syntax. This is a 
> special syntax as well, just happens to be a real language as 
> well.

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 language for real, like CTFE or something.
>
> I don't think that will work. How will the compiler handling 
> imports paths? I need to have all imports path before starting 
> to compile. Otherwise it needs to rescan the source files 
> several times.

Perhaps a better choice of an analogy would be the way unit 
testing is done rather than CTFE, however I will have to be 
specialized for the particular task.

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.

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 OR a programmer specifies all of it manually, which 
is a complete nightmare to maintain on large projects. 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.

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.

Clearly, I don't have all the answers, this is an idea being 
thought out on the fly, so how it will work is entirely up for 
discussion. I'm just trying to think outside the box, looking for 
something much more sensible than the same old messy build system.

--rt