On Fri, 08 Sep 2017, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Sep 06, 2017 at 05:01:42PM +0300, Jani Nikula wrote: >> On Tue, 05 Sep 2017, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote: >> > +configure_file(output: 'config.h', install: false, configuration: config_h) >> >> This makes me think config_h is a misnomer for the configuration data >> object. I'd probably use plain "config" instead. >> >> I think we'll end up wanting to use the configuration data for the test >> runner shell scripts too, and generate a sh.config from the same >> config. We can source the sh.config from e.g. run-tests.sh, to figure >> out the source and build directories. We can use find_program() to find >> piglit, for example, and shove that into sh.config. >> >> Look at the beginning of run-tests.sh and see how much better it could >> be with a sh.config. >> >> Of course, the alternative is to use a separate configuration data >> object for sh.config, but I think it's clearer to use one, and use .in >> files to decide what goes in them. > > configuration_data() seems to just be a special-purpose > wrangler/generator. I use it also for mangling manpages later on iirc. We had a misunderstanding here, clarified on IRC. I meant, do use configuration data, but only use one configuration data object, and generate several outputs from one object. I think we'll benefit from being able to pull in some config data to a sh.config later on, and using that in run-tests.sh and elsewhere. Which means "config_h" will be a slightly misleading name, just call it "config". BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
