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.

Reply via email to