git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v1 0/4] Teach 'run' perf script to read config files

From
Christian Couder <christian.couder@gmail.com>
Date
Jul 26, 2017, 15:58 UTC
Message-ID
<CAP8UFD2NNBN=6GHbQPjz19hQUb+k_43YZBKimaA=3M6m4RH7Tw@mail.gmail.com>
In-Reply-To
<CAP8UFD1FXPtzHF1J5ZfcsmMiHrfXQOd=qEghJQp3eFYsVd-nxQ@mail.gmail.com>

On Fri, Jul 14, 2017 at 8:27 AM, Christian Couder <christian.couder@gmail.com> wrote:

Show 25 quoted lines
> On Thu, Jul 13, 2017 at 10:55 PM, Jeff King <peff@peff.net> wrote:
>> On Thu, Jul 13, 2017 at 08:57:01PM +0200, Christian Couder wrote:
>>
>>> >> We want to make it possible to store the parameters to the 'run'
>>> >> script in a config file. This will make it easier to store, reuse,
>>> >> share and compare parameters.
>>> >
>>> > Because perf-lib is built on test-lib, it already reads
>>> > GIT-BUILD-OPTIONS.
>>>
>>> Actually the 'run' script also sources GIT-BUILD-OPTIONS, so maybe
>>> this is not necessary.
>>
>> Ah, right. The one that comes via perf-lib gets the variables into the
>> test scripts themselves. But anything "run" would need itself would come
>> from the source it does itself. And that's where GIT_PERF_MAKE_OPTS has
>> an effect.
>>
>>> Also are the variables in GIT-BUILD-OPTIONS exported already?
>>
>> No, I don't think so. But because both "run" and the scripts themselves
>> source them, they're available more or less everywhere, except for
>> sub-processes inside the scripts.
>
> Ok, I see.
Actually after taking another look at that, it looks like the following happens:
1) the run script sources the original GIT-BUILD-OPTIONS file from
../.. relative to its location
2) a git version is built in "build/$rev" using GIT_PERF_MAKE_OPTS
which generates a new GIT-BUILD-OPTIONS file in "build/$rev/"
3) when the actual perf scripts are run they source the original
GIT-BUILD-OPTIONS file (through perf-lib.sh which sources test-lib.sh)

I wonder how useful 1) is, as the variables sourced from original GIT-BUILD-OPTIONS are not used inside the "run" script and not available to its child processes as they are not exported. Is it just so that if people add GIT_PERF_* variables to their config.mak before building they can then have those variables used by the run script?

I also wonder if it would be better at step 3) to source the GIT-BUILD-OPTIONS file generated at step 2) instead of the original one, because they can be different as the options in $GIT_PERF_MAKE_OPTS will be baked into the new GIT-BUILD-OPTIONS file. (Of course if $GIT_PERF_MAKE_OPTS was added to config.mak before building, then they will be in the original one too. But $GIT_PERF_MAKE_OPTS should work without that.)

Previous: Jeff KingNext: Jeff King
Message 15 of 16 in “Teach 'run' perf script to read config files”
  1. 0/4 Teach 'run' perf script to read config filesChristian Couder, Jul 13, 2017
  2. 2/4 perf/run: add get_var_from_env_or_config()Christian Couder, Jul 13, 2017
  3. 1/4 perf/run: add '--config' option to the 'run' scriptChristian Couder, Jul 13, 2017
  4. 3/4 perf/run: add GIT_PERF_DIRS_OR_REVSChristian Couder, Jul 13, 2017
  5. 4/4 perf/run: add calls to get_var_from_env_or_config()Christian Couder, Jul 13, 2017
  6. Jeff KingJul 13, 2017
  7. Junio C HamanoJul 13, 2017
  8. Jeff KingJul 13, 2017
  9. Junio C HamanoJul 13, 2017
  10. Christian CouderJul 13, 2017
  11. Christian CouderJul 13, 2017
  12. Jeff KingJul 13, 2017
  13. Christian CouderJul 14, 2017
  14. Jeff KingJul 14, 2017
  15. Christian CouderJul 26, 2017
  16. Jeff KingJul 26, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.