Default variants #144
Default variants #144
Conversation
Any `Tupfile.ini` encountered along the way to the root is parsed as a configuration file (such as the `.tup/options` or `/etc/tup/options` files). The ini files are added to the configuration search in the order they are found, that is a `Tupfile.ini` in the directory `tup` is run from has the highest precedence. Note: This has the interesting property that things in `Tupfile.ini` files are explicitly not project-global unless they are in the root directory of the project. The contents of `Tupfile.ini` files are not tracked in tup's database, rather they are re-parsed on every invocation of tup. This is a design choice, as the configuration elements in the ini files are designed to affect the behavoir of tup as a program, not tup as a build system. In a correct system, the options exposed by the ini files should not be able to affect net result of a build.
This commit adds support for default variants. It adds an option entry called post_init.variants that takes a list of variants to be run. The hook is called any time that `init_command()` is run, whether implicitly or by an explicit tup init. The init() process is re-arranged slightly so that tup is fully init'd when the post_init hooks run. For similar reasons, find_tup_dir is converted to a singleton.
|
On Wed, Oct 23, 2013 at 7:37 PM, Pat Pannuto [email protected]:
So I'd like to propose that post_init.variants not be an in the options [variants] But it wouldn't affect any of the existing options, and no current options I'd also like to suggest that we create a new option that determines How does that sound? I think this would support your use-cases while still Thanks again for splitting these out, |
This pull request adds support for default variants. It depends on PR #133.
Currently it the same as before, it extends the option mechanism to add support for default variants. I'm open to suggestions for how you'd prefer to handle this, but I wanted to have this out here as (1) it's a place to have a discussion and (2) this is used extensively by our lab already, so I didn't want to drop support for it.
One suggestion was to simply have two separate sets of options. The current tup-specific options (e.g. updater.num_jobs) and then project-specific options (e.g. default variants and the aliases previously discussed), where the latter are set in the .ini files but .ini files cannot set the former.