Hi Celli,
On Mon, Jan 1, 2018 at 10:50 AM, Celli Cadgers <[email protected]> wrote:
> Our configuration management system brings versions or configurations of
> tools (inc. compilers) into scope by adjusting PATH, MANPATH, etc. If we
> have multiple variants, perhaps many dozens during portability testing, how
> do we cause tup to export one PATH in one variant and another PATH in
> another variant (similar for other variables) so that each variant sees the
> correct versions of tools based on its PATH?
>
> I could add a CONFIG_PATH=desired:path:foo:bar to the tup.config and then
> change *all* the rules by inserting the variable settings at the font like
> this:
>
> |> export PATH="@{PATH}"; original_script |>
This might be simplified a bit by having the environment variables
exported in a toolchain script that can be sourced. Something like:
: |> . $(MYPROJ_ROOT)/@(TOOLCHAIN); original_script |>
And you can put things like 'foo.cfg' and 'bar.cfg' at the top-level
of your project (assuming you set MYPROJ_ROOT in a Tuprules.tup file).
Then you can set CONFIG_TOOLCHAIN=foo.cfg in tup.config to source
those files, and still all of the export definitions needed for the
toolchain in the .cfg files. Still annoying, but at least you'd have
the full configuration of those environment variables in one place.
> But that seems error prone in a large project with many developers. Plus it
> doesn't change the fact that tup will still try to rerun commands if tup's
> PATH changes.
The PATH environment variable is always going to be hard-coded as a
dependency for all commands, since that impacts the shell. If you have
the toolchain details encoded in a file, would something else still be
changing the PATH that tup sees regularly?
> I could also tell all the developers to use --no-environ-check, but that
> would affect all environment variables, including some that we might want to
> export through tup. What I need is some finer granularity of control and in
> a way that doesn't put a burden on other developers that might need to write
> an occassional :-rule.
>
> Assuming there's not an easy way to accomplish what we need, I have a
> feature request...
>
> Feature request: Allow the "export" command to take an optional second
> parameter. If a second parameter is present, then export (and save in the
> database) the variable with that value rather than the value from tup's
> environment. Examples:
> export PAGER cat
> export PATH @{PATH}
>
> Variation: instead of two parameters, use an '=' like in the shell:
> export PAGER=cat
> export PATH=@{PATH}
> which allows empty values not possible in the first variation:
> export PAGER= // exports an empty value
> export PAGER // exports value from tup's environ
I think there was a discussion on this before, but I can't seem to dig
it up at the moment. I think this would be a good addition, and would
favor the export FOO=bar syntax. The main difficulty in implementing
it is figuring out how to store the different values in the database
if the same name can have multiple values. Eg currently in tup, a
Tupfile like this:
: |> echo "1: ${FOO}" |>
export FOO
: |> echo "2: ${FOO}" |>
when run with 'FOO=bar tup', shows:
1) [0.015s] echo "1: ${FOO}"
1:
2) [0.027s] echo "2: ${FOO}"
2: bar
In the database, there is an entry for the variable 'FOO' which has a
link to the second command. This could be confusing if there is more
than one possible value for 'FOO', like in this example using the
proposed syntax:
export FOO=test1
: |> echo "1: ${FOO}" |>
export FOO=test2
: |> echo "2: ${FOO}" |>
Somehow tup would need to have an entry for both FOO variables, with
two different values. I'm not sure the best approach to take for that.
If that can be sorted, I think it would be a useful addition.
Thanks for the feedback!
-Mike
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
