mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Christian Couder <>
To: Jeff King <>
Cc: git <>, "Junio C Hamano" <>,
	"Thomas Rast" <>,
	"Ævar Arnfjörð Bjarmason" <>,
	"Christian Couder" <>
Subject: Re: [PATCH v1 0/4] Teach 'run' perf script to read config files
Date: Fri, 14 Jul 2017 08:27:53 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Thu, Jul 13, 2017 at 10:55 PM, Jeff King <> 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
>> 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.

>> > And the Makefile copies several perf-related values
>> > into it, including GIT_PERF_MAKE_OPTS and GIT_PERF_REPEAT_COUNT. So you
>> > can already do:
>> >
>> >   echo 'GIT_PERF_REPEAT_COUNT = 10' >>config.mak
>> >   echo 'GIT_PERF_MAKE_OPTS = CFLAGS="-O2" DEVELOPER=1' >>config.mak
>> >   make
>> The "make" here might not even be needed as in the 'run' script
>> "config.mak" is copied into the "build/$rev" directory where "make" is
>> run to build the $rev version.
> You need it to bake the config into GIT-BUILD-OPTIONS, which is the only
> thing that gets read by "run" and the perf scripts. If you are
> just setting MAKE_OPTS to things that your config.mak already sets, then
> yes, you can skip that one.

Thanks for the explanations.

The whole thing seems really complex to me though. And this makes me
think that people might want to specify different GIT-BUILD-OPTIONS
and config.mak files to be used when running perf tests, so that the
results from perf tests can easily be reproduced later even if they
have changed their build options in their development Git repo in the

So perhaps the config file should make it possible to specify a
directory where all the build files (GIT-BUILD-OPTIONS, config.mak,
config.mak.autogen and config.status) that should be used should be
taken. And then it could also let people change some variables to
override what is in those files which is needed to run perf tests with
different parameters.

  reply	other threads:[~2017-07-14  6:27 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-13  6:50 [PATCH v1 0/4] Teach 'run' perf script to read config files Christian Couder
2017-07-13  6:50 ` [PATCH v1 1/4] perf/run: add '--config' option to the 'run' script Christian Couder
2017-07-13  6:50 ` [PATCH v1 2/4] perf/run: add get_var_from_env_or_config() Christian Couder
2017-07-13  6:50 ` [PATCH v1 3/4] perf/run: add GIT_PERF_DIRS_OR_REVS Christian Couder
2017-07-13  6:50 ` [PATCH v1 4/4] perf/run: add calls to get_var_from_env_or_config() Christian Couder
2017-07-13 16:58 ` [PATCH v1 0/4] Teach 'run' perf script to read config files Jeff King
2017-07-13 18:29   ` Junio C Hamano
2017-07-13 18:40     ` Jeff King
2017-07-13 19:21       ` Junio C Hamano
2017-07-13 19:45       ` Christian Couder
2017-07-13 18:57   ` Christian Couder
2017-07-13 20:55     ` Jeff King
2017-07-14  6:27       ` Christian Couder [this message]
2017-07-14  8:05         ` Jeff King
2017-07-26 15:58         ` Christian Couder
2017-07-26 16:54           ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).