ReBench icon indicating copy to clipboard operation
ReBench copied to clipboard

Support for passing on Environment variables

Open krono opened this issue 11 years ago • 3 comments

It would be nice to pass on environment variables to the binary/vm

  • on a per-binary basis
  • on a per-benchmark basis
  • on a per-suite basis
  • on a per-experiment basis (and so on)

krono avatar Oct 02 '14 09:10 krono

Hm, well, perhaps it helps if I give you some hints how to start adding it? :)

Ideally, you start with writing a test in tests/features. There you can design the relevant 'language' changes in a issue_42.conf file. The implementation adaptations are more or less localized to the model package. Combining and merging logic for the different configuration parts should probably be the same as for most of the others. In the end, a RunId, will probably need something to construct an environment similar to the way it constructs the cmdline.

And then, in execute_run you'll need to pass it through to the eventual call of Popen to give it to its env parameter...

Thinking about it, the reporters need then to get the environment for completeness, as well, I guess.

So, not a very trivial change. Not hard, but you'll need to touch a lot of things to get it right.

smarr avatar Oct 02 '14 09:10 smarr

Based on a discussion with @charig:

I could imagine support for environment variables like this:

MyBenchmark:
  command: foobar
  env:
    MY_VAR: %(input)s
    BAZ: sdfsdfsdf

It might be good to simply add it to EXP_RUN_DETAILS here https://github.com/smarr/ReBench/blob/master/rebench/rebench-schema.yml#L6

This way, there are plenty of places where it could be adapted. Though, there is some conceptual mismatch between what's there already and the env settings. So, it may as well go simply to VM and suite.

smarr avatar Jul 25 '18 17:07 smarr

The first step for this is done with #174, building in spirit on @charig's work and directly based on @OctaveLarose's implementation.

I won't add support for expanding variables yet, since this requires careful work around RunId identity, which is currently only considers the command line.

This means, at the moment, env var support is limited in usefulness since different env vars do not mean different run ids. Thus, if runs only differ by the env var, we won't be able to distinguish them.

smarr avatar Jul 05 '22 11:07 smarr