Pass argument to build script

[eatdrinksleepcode]

We already have an issue for passing arguments to individual tasks (#58). However, it would also be useful to be able to pass arguments to the build script itself. For example, in Bau's current build script, the "Release" configuration is hard-coded in several places. It would be nice to be able to specify this from the command line.

This would be equivalent to -P (project properties) in Gradle. Maven uses -D (Java system properties) and Rake allows environment variables to be set from the command line to achieve similar functionality.

[aarondandy]

I also would love a way to handle this. Currently my workaround is to have a task like "set-release" while I default to Debug where the set-release changes a global variable for the configuration. Then I just define a "publish" task that runs "set-release" then "default".

[eatdrinksleepcode]

So I can think of three questions to answer: 1) how should such arguments be set on the command line, 2) how should they be accessed in the script, and 3) what terminology do we use?

1. Gradle uses "-Pconfiguration=Release" (where P stands for property), which is a derivation of the Java standard "-Dconfiguration=Release" for system properties (which is what Maven uses). Rake doesn't use a switch; rather you can simply specify "configuration=Release" and this is recognized as an environment variable. I prefer the switch primarily because it seems less ambiguous with task names without relying on the presence of the equals sign (this also potentially simplifies the use case of enabling boolean properties by just specifying the name of the property without the value).

   The question then is, what kind of switch. Bau currently recognizes "-loglevel trace" and "-t". We could use the same syntax for script properties, e.g. "-configuration Release". My concern with this approach is that we would have to disable the switch validation in the argument parsing, since we don't know what arguments are expected (unless we find some way of declaring the arguments in the script, but I think that would be difficult to do in a clean and intuitive). This means that a typo in a known switch like loglevel won't be caught, and execution will continue as if the switch were not specified. If instead we require a switch token to be specified, e.g. "-Pconfiguration=release" or "-Pconfiguration release", we can retain the validation for known switches. However, the consequences of not catching a typo in a known switch are not very high, and the user will presumably notice that the switch has not taken effect and then find their mistake.

   If we do use a switch token, the only remaining question is whether to separate the name from the value with an equals (=) or a space, or something else. I am partial to the equals, both because I think it would be easier to parse (no need for look ahead) and because it is what I am used to from the other build systems I use. Neither of those is a strong reason, but from a usability perspective I feel they are about the same, so I don't have a strong opinion here.

2. The simplest way to expose these in the script is probably a method on Bau, e.g. Require<Bau>().GetProperty("configuration"). Given the way ScriptCS works, I can't think of any other simple way of exposing them.

3. Gradle and Maven refer to them as "properties". Rake doesn't have a specific term for them since it is reusing "environment variables", which I don't think accurately describes what we want. The only other appropriate term I can think of is "arguments".

[aarondandy]

I am working in Visual Studio Online now and with their new secured variable setup I will need to pass some things as parameters. If we can come up with an implementable design I may be able to put time into this as I need it.

[eatdrinksleepcode]

To summarize my rambling soliloquy above, my proposal is:

1. Command line:

   scriptcs bau.csx -- build -Pconfiguration=Release

2. Script file:

   msb.Properties = new { Configuration = bau.GetProperty("configuration", "Release") };

   (note the default value of "Release" in the GetProperty call).

[aarondandy]

Personal taste I guess but -Pthingy=stuff is not so easy on the eyes. What about -parameters "Thing1=one;Thing2=two things" or -p Thing1=one -p "Thing2=two things" . I suppose the first way of doing it gets weird if there are any ; characters in a value. Just thinking out loud really...

[eatdrinksleepcode]

I would be ok with -p Thing1=one -p "Thing2=two things". Strikes a good balance between readability and parsability I think.

[aarondandy]

Next question to sort out: A) scriptcs bau.csx -- -p key=value build

or

B) scriptcs bau.csx -- build -p key=value

Either way I think this will require a large change to how arguments are parsed in Bau.

[aarondandy]

Any work done on this issue will likely clash with changes in PR #203 as it also made changes to argument parsing code.

[adamralph]

FYI #203 is close to being merged

[eatdrinksleepcode]

@aarondandy I would think we could allow for either order without a significant change to argument parsing. It already does look-ahead, doesn't it?

[adamralph]

I like the -p Thing1=one -p "Thing2=two things" proposition and yes, this should just fit in to the current arg parsing logic without too much change required.

[karthik25]

I know this is 9 months old, but I am definitely considering taking a shot at this (-p Thing1=one ...)! It would help for what I am trying to achieve w/ bau!!