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.
