4

I am developing a complex build script with Shake, but (for now) I'm using Visual Studio solutions to build all of the binaries. Because of this, I need to define a rule that builds dozens of files in a single sweep. I don't know what the build outputs will be until it's done.

So, for example, I want to write rules like this:

"test-bins-x86" ~> do
    vsBuild unitTestSln X86 Release -- produces dozens of outputs to .\x86\Release

"x86/Release/*.test-results" *> \out -> do
    let testExe = out -<.> exe
    need [testExe]
    Stdout results <- cmd testExe
    writeFile' out results

But, as it stands, the rule for *.test-results does not know how to build testExe because no rules formally define how. How can I work around this?

Elliot Cameron
  • 5,235
  • 2
  • 27
  • 34

1 Answers1

3

I have two possible solutions, and a comment. First the comment: if you don't know what the outputs of the build will be in advance, how can you know that testExe will exist? What should you do if it doesn't? Is there a subset of executables that you can assume are always built? Does it depend on other files that may exist, or the environment?

My first idea is to make your "test-bins-x86" a phony, and have every action that would need a particular executable instead need that phony. This will probably work, unless you need to invoke the VS build system multiple times per shake build run.

The other approach is possibly something using FilePatterns and %>, like this:

"x86/Release/*" %> \ _ -> need ["test-bins-x86"]

This could be expanded upon if required, and furthermore you could check if the executable were actually produced via this rule and do something else in case it wasn't.

If it were possible to determine in advance what the build outputs would be, I would suggest you use &%>, but if that information is unavailable you can't use that operator.

Elliot Cameron
  • 5,235
  • 2
  • 27
  • 34
John L
  • 27,937
  • 4
  • 73
  • 88
  • I think using the `FilePattern`s approach is good, with one tweak - you should probably use a dummy file (say `x86/Release/stamp.exes`) rather than a phony rule so that it is properly tracked and rebuilds in all the right places - need'ing a phony is usually a bad idea. – Neil Mitchell Oct 25 '14 at 07:23
  • @NeilMitchell using a dummy file is a good idea. There's one thing I'm not clear on yet though, which is whether or not the inputs for `vsBuild` are tracked by shake. If they aren't, I suppose the dummy file would need to be cleaned before rebuilding. – John L Oct 25 '14 at 18:25
  • It really depends on the definition of `vsBuild` - ideally it would call a bunch of `need` statements first so the dependencies are well known. If not, you would need to clean/touch it manually. – Neil Mitchell Oct 26 '14 at 16:30