Tobias Schlitt wrote:
On 04/14/2011 11:36 AM, Jerome Renard wrote:
I still prefer cli options than env vars for 90% of the time though, as it's
easier to understand what is happening when the options are explicit.
But, as far as I can see in your code, what you can do is that you can swap
out one config file with another.
What I was asking to is to separate cofig options: one set that is
project-specific (stored in the config file), and one set that is specific
to the build environment (passed via cli options or env vars).
I'll see how to pass arguments from the command line in Pake then.
I'd suggest to use some kind of "properties" file for configuration.
Yaml is the pake-equivalent of properties. Is it fine with you to have yaml
files for config?
At least that is what we do when using ant. Our scripts ship with a
build.properties file and the script itself looks for
build.local.properties. If this doesn't exist, it bails out with a
message that the user should copy and adjust the original file.
This way is pretty convenient and most obvious I'd say.
Kind of ok, but why not instead:
- take properties from build.properties file (which is complete)
- if build.local.properties is there, use it to override existing properties
(if it's not where, just continue)
This way there is no need to copy files around, and the original properties
file can be kept in sync easily with the upstream svn/git version.
