On Friday, 3 April 2015 at 17:40:42 UTC, Dicebot wrote:
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.

Well, I took your advice (and one of my acceptance tests is based off of your simplified real-work example) and started with the low-level any-command-will-do API first. I built the high-level ones on top of that. It doesn't seem crazy to me that certain builds can only be done by certain backends. The fact that the make backend can track C/C++/D dependencies wasn't a given and the implementation is quite ugly.

In any case, the Target structs aren't high-level abstractions, they're just data. Data that can be generated by any code. Your example is basically how the `dExe` rule works: run dmd at run-time, collect dependencies and build all the `Target` instances. You could have a D backend that outputs (then compiles and runs) your example. The "only" problem I can see is execution speed.

Maybe I didn't include enough examples.

I also need to think of your example a bit more.

Reply via email to