On 2012-11-29 19:53, Rob T wrote:
The very last thing I would want to do is to futz around installing Ruby
and learning Ruby for the sole purpose of building a D application.
Ruby would not be a runtime dependency. It's embedded in the tool just
like any other library. BTW, I never heard anyone complain about the
DSSS build scripts. Which is completely custom, something like a
combination of ini files and statements. Ruby is at least a real
language. An example from DSSS:
version (build) {
pragma(link, "example");
}
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.
Think about how massive a time sink that is for anyone who has no other
reason to invest their valuable time into Ruby. I got sucked into this
trap with Make, which wasted many hours of what should have been
productive time, and I saw the exact same issues repeat when I
investigated scons as a potential alternative. I just fail to see why
this kind of complexity is necessary at all. If we can fix the problem
at the source, then we should do it, rather than pile more mess on top
of the existing pile of mess.
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.
I do however think you have a good point wrt the use of "comments" for
doing this stuff. Please do not use comments for this, make it a part of
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.
--
/Jacob Carlborg
