InputTasks are difficult to combine

[derekwyatt]

I'd like to create a new configuration that compiles some LaTeX and others into a final book. This book relies example code that can be compiled and tested. When working on a small section of the book, it is desirable to be able to do a 'test-only' on the small section of code that the book is talking about.

To compile the book, I created the "book" configuration - config(BookConfig) extend (Compile, Test).

What I'd like to do is create a 'sequence' of tasks that are triggered like this:

book:test-only my.specific.test.Spec

This should:

• Compile the code
• Compile the test code
• Execute the test code
• Compile the book

Any failure in these steps should terminate the chain prematurely.

Because test-only is an input task, making this arrangement is problematic. I'm not clear on the full details as to "why" but this email thread should suffice to illuminate the point:

http://groups.google.com/group/simple-build-tool/browse_thread/thread/2a2f28acb7a7a699?hl=en

[SethTisue]

This interests me as well. I wanted to do the same thing, beat my head on it for a long time, and eventually found this ticket.

Mark you wrote "InputTask[Unit]... is basically a function of String => Task[Unit]". yeah, exactly, conceptually that's what I thought it was, so I assumed it would be reasonably straightforward to use it that way.

in the meantime, what I ended up doing was copying and pasting the testOnly code from Defaults.scala and then customizing it. here's the commit, in case it helps anyone trying to do something similar in their own build: NetLogo/NetLogo@70c78fd. Not really sure how correct the details are. The part I got stuck on a long time was that you need to add Defaults.testTaskOptions to your tasks, otherwise they almost work except the output from the test framework disappears, for lack of an appropriate value for the testListeners key. Also, note that this is code for 0.11.3. I see that the details of how test-only works have already changed for 0.12/0.13.

[SethTisue]

and here it is modified to produce one InputTask from another InputTask: NetLogo/NetLogo@818425c

that's for 0.11.3. for 0.12.0-RC1 it's a little different:
NetLogo/NetLogo@58ab8f0

[nartamonov]

I suppose this problem leads to very annoy difficulties which are trivial in other build systems. For example, we haven't simple way to abstract over task 'run' with arguments: 'run arg1 arg2 arg3', so we could simply write 'runWithPredefinedArgs'. See https://groups.google.com/d/topic/simple-build-tool/tHvNHGSgZg4/discussion. In my practice this inconvenience force me to invent ugly hacks and spend much time.

Wish this issue be marked with high priority.

[hrjet]

I am here for the ability to define a task for run arg1 arg2 arg3. The reason I need to define this task is so that other tasks can depend on it. I don't want to use hacks, so I am forced to use a Makefile for it!

[SethTisue]

three cheers for .toTask — with the help of that and inputTaskDyn, I was finally able to get rid of that hairy stuff in my build and directly reuse the existing testOnly task. so nice: NetLogo/NetLogo@64bc23f

[harrah]

That is nice indeed. Glad it helps!