Add simplified syntax

[ndmitchell]

Add a basic syntax for interpreting YAML (probably) as Shake rules. Could easily store rules in that form, have a loadRulesFromYaml function, and allow them to be run by default. If we make it more powerful than Ninja (to translatable) then should be easy.

[ndmitchell]

As a straw man:

want file.txt
$dir//$file.txt:
    need _make/$dir/$file.foo
    gcc -c $file.foo -o $file.txt

[ndmitchell]

Proposal two:

include File.extra_defns # allow pulling in extra files, with a path relative to current file
need file.txt file2.txt
$make = _make
$dir//$file.txt
    need $make/$dir/$file.foo
    $output = $file.txt
    need $dir/$file.bar                           # an additional requirement halfway through
    gcc -c $file.foo -o $output
phony clean
    rm -rf $make

And as special features, need, needLines and needMakefile can be used to need either an explicit list of files, a file containing files one per line, or a makefile RHS's.

For escaping, I would make $() be equivalent to a literal $, $( ) be a literal space, and $(file) be $file, but useful for things like $dir//$(file)foo.txt.

@somenxavier, any thoughts on this proposal?

[ghost]

I see more complicated than first proposal.

[ndmitchell]

I simplified it very slightly as an edit to the comment. If you look, the first proposal is basically a subset of the second proposal - I've just added a couple of things that are likely to be essential (include files, variable definition, phony). I'm not sure there is anything in the second proposal that could be removed without significantly limiting what it can do.

[refi64]

Some thoughts:

• Targets should end in a :, just like in YAML. It makes things a little clearer and more obvious.
• Assignment shouldn't start with a $. That would inflict slight parsing hell(would that be an expression or a statement?) That isn't a problem, though, if you're using an LALR parser.
• Treating a command to execute as anything that isn't a statement is bad, largely if you need to run a program named need(that would suck).

Just to put an idea in: you really don't need it be laid out like an imperative program. Take Google GYP. It has no imperative statements; it's actually laid out somewhat like a functional language. What if YAML is used with that idea? Something like:

variables:
    x:
        if 1 == 1: 1
        else: 2
    src: x.c

rule abc:
    need:
        - "$(src)"
    formula: gcc %d -o %o

I was going to write a Makefile generator that used this idea, but I never got the chance.

[ndmitchell]

I'm not too fussed about the parsing, I was just going to have $[A-Z]+[ ]*= be treated as a definition, but prepending var seems easy enough (and probably cleaner). You can always add $(need) as a variable which evaluates to need, allow you to escape the need keyword - I'd rather not have keywords for commands since they are really the standard thing. Adding a : at the end of a target does feel more natural, so I'm happy with that. However, these parsing issues are just strawman proposals, and can be easily tweaked.

As for the imperative/functional approach, I don't really want to support conditionals/comparison etc. in the language at all. If you need that, use a real language (specifically Haskell), the plan is only simple textual substitution, no functions, no equality. I think the imperative flavour is necessary to express all the power of Shake - you want to have a rule which runs a command, does a need, then runs another command, as that is Shake's big selling point. That very naturally fits into a list of statements.

[ndmitchell]

My inclination is that for the build systems where Shake is ideally suited, you tend to end up writing an interpreter anyway, and then you need the full power of Haskell. A "simple end" Shake might be valuable for small projects, but it doubles the number of syntaxes to document and halves the reusability of questions, so I'm not going to do it. If anyone wants to build such a lite-Shake language I'd be very keen to see it and happy to link to it.

[Mathnerd314]

You already wrote a Sake implementation, which is in fact a simplified YAML syntax: http://neilmitchell.blogspot.com/2014/05/shake-as-dependency-library.html Perhaps running the Sake test suite could be part of Shake's test suite?

[ndmitchell]

Sake is a simplified YAML syntax, but it also doesn't give access to any of the powerful Shake features, so I don't really want to push people down that route. I also don't remember much of Sake, and don't really want to support that code (there's a reason it's a blog post and not part of Shake by default).

I suspect the Sake test suite would be great to test the Sake implementation above, so if anyone ever did decide to turn it into a proper project, that would be very useful. In contrast, there are no .ninja tests in the Ninja repo, which makes the Ninja binding much harder (there are tests, but they poke the C++ internals, which seems a weaker form of test). However, as it stands, I'm not sure there's much point in integrated the Sake tests.