multiple targets shake

[nicolas...@gmail.com]

What is the best way to use shake to manage a project, where there are multiple targets ?

I have to build haskell projects with stack - of course -, build some javascript, minify some assets, deploy to heroku or some provider, set some variables upon deployment, etc, etc....

--

I was thinking in the spirit of the shake --demo to make a small binary where I essentially parse that arguments to select the target to build, and why not add some optparse use to add some options on commands.

That sounds to me both :
- a perfect fit dealing magically with many issues one has to deal with anyway and
- an overkill compared to what I usually think in terms of build system.

Any opinion on which one it is ?

[Evan Laforge]

Maybe I misunderstand the question, but I do:

Shake.shakeArgsWith defaultOptions [] $ \[] targets -> return $ Just $ do
... add rules
Shake.want targets

It's actually a bit more complicated because I have a bunch of fake
targets like "clean", but that's the idea.

[Nicolas R]

how do you specify which target to you want shake to build or what options are relevant for that target ? 

--

Nicolas Rolland
mobile : +33 6 62 88 42 92

[Evan Laforge]

On Wed, Nov 25, 2015 at 10:32 AM, Nicolas R <nicolas...@gmail.com> wrote:
> how do you specify which target to you want shake to build or what options
> are relevant for that target ?

Just on the command line, so e.g. compile Shakefile.hs to mk and then
'mk x y z'. I infer the options based on the target path, so e.g. 'mk
build/opt/x build/debug/x' will build both the debugging and optimized
versions of 'x'.

[nicolas...@gmail.com]

so you compile a binary, thats what I was thinking of doing.

but as for options, there are some nice libraries like optparse-applicative or getopt-generics which allows you to specify advanced parsers and subcommands

it would be great to build a bridge between the two but I dont know what is the best option to expose the most in as little plumber code as possible

[Neil Mitchell]

> so you compile a binary, thats what I was thinking of doing.

Whether you compile as a binary or not really depends on how big your
project is - if runhaskell Shakefile.hs has no noticeable impact,
that's easier, but if it does add a ghc --make somewhere.

> but as for options, there are some nice libraries like optparse-applicative or getopt-generics which allows you to specify
> advanced parsers and subcommands

If you use shakeArgs you get complete command line parsing with
roughly Make compatible arguments (e.g. -j, --profile, --keep-going),
plus any names on the command line get turned into a want. Given a
name "foo.txt", it will build the file "foo.txt" using the standard
rules, or if you use phony, you can declare phony "clean" ..., and
then "mk clean" will clean your project.

If you use shakeArgsWith you can add some custom arguments (e.g. a
--debug, --x86) and also interpret the name arguments differently. For
an example of extra arguments see the docs, or see real examples such
as MinGHC (https://github.com/fpco/minghc/blob/master/Main.hs#L47).
For interpreting names differently, I have used debug=1 to treat as a
CPP definition rather than a needed file.

> it would be great to build a bridge between the two but I dont know what is the best option to expose the most in as
> little plumber code as possible

If you use the shake function, then you pass a ShakeOptions structure,
and can have full control over all command line parsing, using
whatever command line parser you like. You'll have to replicate the -j
options (or at least the subset you care about), but it shouldn't be
too hard. I've done that, using CmdArgs as the parser library, for a
multi-function executable with subcommands.

Thanks, Neil