On Friday, 3 April 2015 at 17:17:50 UTC, Atila Neves wrote:
On Friday, 3 April 2015 at 17:13:41 UTC, Dicebot wrote:
Also I don't see any point in yet another meta build system.
The very point of initial discussion was about getting D only
cross-platform solution that won't require installing any
additional software but working D compiler.
I was also thinking of a binary backend (producing a binary
executable that does the build, kinda like what ctRegex does
but for builds), and also something that just builds it on the
spot.
The thing is, I want to get feedback on the API first and
foremost, and delegating the whole
do-I-or-do-I-not-need-to-build-it logic to programs that
already do that (and well) first was the obvious (for me)
choice.
Also, Ninja is _really_ fast.
The thing is, it may actually affect API. The way I have
originally expected it, any legal D code would be allowed for
build commands instead of pure DSL approach. So instead of
providing high level abstraction like this:
const mainObj = Target("main.o", "dmd -I$project/src -c $in
-of$out", Target("src/main.d"));
const mathsObj = Target("maths.o", "dmd -c $in -of$out",
Target("src/maths.d"));
const app = Target("myapp", "dmd -of$out $in", [mainObj,
mathsObj]);
.. you instead define dependency building blocks in D domain:
struct App
{
enum path = "./myapp";
alias deps = Depends!(mainObj, mathsObj);
static void generate()
{
import std.process;
enforce(execute([ "dmd", "-ofmyapp", deps[0].path,
deps[1].path]).status);
}
}
And provide higher level helper abstractions on top of that,
tuned for D projects. This is just random syntax I have just
invented for example of course. It is already possible to write
decent cross-platform scripts in D - only dependency tracking
library is missing. But of course that would make using other
build systems as backends impossible.
