Re: [Intel-gfx] [PATCH i-g-t 12/22] meson: basic build system support

[Jani Nikula]

On Fri, 08 Sep 2017, Daniel Vetter  wrote:
> On Wed, Sep 06, 2017 at 05:01:42PM +0300, Jani Nikula wrote:
>> On Tue, 05 Sep 2017, Daniel Vetter  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 12/22] meson: basic build system support

[Daniel Vetter]

On Wed, Sep 06, 2017 at 05:01:42PM +0300, Jani Nikula wrote:
> On Tue, 05 Sep 2017, Daniel Vetter  wrote:
> > Why?
> >
> > Because it's fast.
> 
> And that's not even the main reason from my perspective! ;)
> 
> Please find some comments inline. None of them are blockers.
> 
> BR,
> Jani.
> 
> >
> > Like really, really fast.
> >
> > Some data (from a snb laptop, so rather lower-powered):
> >
> > - Incremental build after $ touch lib/igt_core.c with meson: 0.6s
> >   It notices that the symbol list of the libigt.so hasn't changed and
> >   doesn't bother re-linking the almost 300 binaries we have. make -j 6
> >   for the same scenario takes 44s.
> >
> > - Incremental build with nothing changed: make: 0.7s, meson: 0.2s This
> >   means stuff like --disable-git-hash is entirely pointless with
> >   meson, it's faster than a make ever can be (with 0.6s).
> >
> > - Reconfigure stage: ninja reconfigure 0.8s vs. ./configure 8.6s)
> >
> > - Running tests, after a full build: ninja test 6s vs. make check 24s
> >
> > - Full build (i.e. including ./autogen.sh respectively meson build),
> >   including tests, from a pristine git checkout. automake 2m49s vs.
> >   meson 44s.
> >
> > Cc: Ville Syrjälä 
> > Cc: Eric Anholt 
> > Cc: Daniel Stone 
> > Signed-off-by: Daniel Vetter 
> > ---
> >  .gitignore   |   1 +
> >  assembler/meson.build|  73 ++
> >  benchmarks/meson.build   |  36 +
> >  lib/meson.build  | 166 ++
> >  lib/prepend_log_domain.sh|   8 ++
> >  lib/tests/meson.build|  34 +
> >  lib/version.h.in |   1 +
> >  meson.build  | 105 ++
> >  overlay/meson.build  |  59 
> >  tests/generate_testlist.sh   |  10 ++
> >  tests/meson.build| 290 
> > +++
> >  tools/meson.build|  59 
> >  tools/null_state_gen/meson.build |  15 ++
> >  13 files changed, 857 insertions(+)
> >  create mode 100644 assembler/meson.build
> >  create mode 100644 benchmarks/meson.build
> >  create mode 100644 lib/meson.build
> >  create mode 100755 lib/prepend_log_domain.sh
> >  create mode 100644 lib/tests/meson.build
> >  create mode 100644 lib/version.h.in
> >  create mode 100644 meson.build
> >  create mode 100644 overlay/meson.build
> >  create mode 100755 tests/generate_testlist.sh
> >  create mode 100644 tests/meson.build
> >  create mode 100644 tools/meson.build
> >  create mode 100644 tools/null_state_gen/meson.build
> >
> > diff --git a/.gitignore b/.gitignore
> > index 6204965a0e32..e6919272d8b6 100644
> > --- a/.gitignore
> > +++ b/.gitignore
> > @@ -93,3 +93,4 @@ intel-gpu-tools-*/
> >  
> >  piglit
> >  results
> > +build
> > diff --git a/assembler/meson.build b/assembler/meson.build
> > new file mode 100644
> > index ..b0e2db25
> > --- /dev/null
> > +++ b/assembler/meson.build
> > @@ -0,0 +1,73 @@
> > +lib_brw_src = [
> > +   'brw_context.c',
> > +   'brw_disasm.c',
> > +   'brw_eu.c',
> > +   'brw_eu_compact.c',
> > +   'brw_eu_debug.c',
> > +   'brw_eu_emit.c',
> > +   'brw_eu_util.c',
> > +   'gen8_disasm.c',
> > +   'gen8_instruction.c',
> > +   'ralloc.c',
> > +]
> 
> FWIW I like this style of assigning lists.
> 
> > +
> > +lib_brw = shared_library('brw', lib_brw_src,
> > +   dependencies : igt_deps)
> 
> The Emacs meson mode nicely indents the continuation lines after the
> opening (. These seem off... all over the place.
> 
> > +
> > +flex = find_program('flex')
> > +bison = find_program('bison')
> > +
> > +lgen = generator(flex,
> > +   output : '@BASENAME@.c',
> > +   arguments : ['-o', '@OUTPUT@', '@INPUT@'])
> > +
> > +lfiles = lgen.process('lex.l')
> > +
> > +pgen = generator(bison,
> > +   output : ['@BASENAME@.c', '@BASENAME@.h'],
> > +   arguments : ['@INPUT@', '--defines=@OUTPUT1@', 
> > '--output=@OUTPUT0@'])
> > +
> > +pfiles = pgen.process('gram.y')
> > +
> > +executable('intel-gen4asm', 'main.c', lfiles, pfiles, link_with : lib_brw)
> > +
> > +executable('intel-gen4disasm', 'disasm-main.c', link_with : lib_brw)
> > +
> > +gen4asm_testcases = [
> > +   'test/mov',
> > +   'test/frc',
> > +   'test/rndd',
> > +   'test/rndu',
> > +   'test/rnde',
> > +   'test/rnde-intsrc',
> > +   'test/rndz',
> > +   'test/lzd',
> > +   'test/not',
> > +   'test/immediate',
> > +]
> > +
> > +# Those tests were already failing when the assembler was imported from
> > +# the intel-gen4asm git repository:
> > +#   http://cgit.freedesktop.org/xorg/app/intel-gen4asm/
> > +# We disable them "for now" as a workaround to be able to release i-g-t
> > +gen4asm_testcases_broken = [
> > +   'test/declare',
> > +   'test/jmpi',
> > +   'test/if',
> > +   'test/iff',
> > +   'test/while',
> > +   'test/else',
> > +   

Re: [Intel-gfx] [PATCH i-g-t 12/22] meson: basic build system support

[Jani Nikula]

On Tue, 05 Sep 2017, Daniel Vetter  wrote:
> Why?
>
> Because it's fast.

And that's not even the main reason from my perspective! ;)

Please find some comments inline. None of them are blockers.

BR,
Jani.

>
> Like really, really fast.
>
> Some data (from a snb laptop, so rather lower-powered):
>
> - Incremental build after $ touch lib/igt_core.c with meson: 0.6s
>   It notices that the symbol list of the libigt.so hasn't changed and
>   doesn't bother re-linking the almost 300 binaries we have. make -j 6
>   for the same scenario takes 44s.
>
> - Incremental build with nothing changed: make: 0.7s, meson: 0.2s This
>   means stuff like --disable-git-hash is entirely pointless with
>   meson, it's faster than a make ever can be (with 0.6s).
>
> - Reconfigure stage: ninja reconfigure 0.8s vs. ./configure 8.6s)
>
> - Running tests, after a full build: ninja test 6s vs. make check 24s
>
> - Full build (i.e. including ./autogen.sh respectively meson build),
>   including tests, from a pristine git checkout. automake 2m49s vs.
>   meson 44s.
>
> Cc: Ville Syrjälä 
> Cc: Eric Anholt 
> Cc: Daniel Stone 
> Signed-off-by: Daniel Vetter 
> ---
>  .gitignore   |   1 +
>  assembler/meson.build|  73 ++
>  benchmarks/meson.build   |  36 +
>  lib/meson.build  | 166 ++
>  lib/prepend_log_domain.sh|   8 ++
>  lib/tests/meson.build|  34 +
>  lib/version.h.in |   1 +
>  meson.build  | 105 ++
>  overlay/meson.build  |  59 
>  tests/generate_testlist.sh   |  10 ++
>  tests/meson.build| 290 
> +++
>  tools/meson.build|  59 
>  tools/null_state_gen/meson.build |  15 ++
>  13 files changed, 857 insertions(+)
>  create mode 100644 assembler/meson.build
>  create mode 100644 benchmarks/meson.build
>  create mode 100644 lib/meson.build
>  create mode 100755 lib/prepend_log_domain.sh
>  create mode 100644 lib/tests/meson.build
>  create mode 100644 lib/version.h.in
>  create mode 100644 meson.build
>  create mode 100644 overlay/meson.build
>  create mode 100755 tests/generate_testlist.sh
>  create mode 100644 tests/meson.build
>  create mode 100644 tools/meson.build
>  create mode 100644 tools/null_state_gen/meson.build
>
> diff --git a/.gitignore b/.gitignore
> index 6204965a0e32..e6919272d8b6 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -93,3 +93,4 @@ intel-gpu-tools-*/
>  
>  piglit
>  results
> +build
> diff --git a/assembler/meson.build b/assembler/meson.build
> new file mode 100644
> index ..b0e2db25
> --- /dev/null
> +++ b/assembler/meson.build
> @@ -0,0 +1,73 @@
> +lib_brw_src = [
> + 'brw_context.c',
> + 'brw_disasm.c',
> + 'brw_eu.c',
> + 'brw_eu_compact.c',
> + 'brw_eu_debug.c',
> + 'brw_eu_emit.c',
> + 'brw_eu_util.c',
> + 'gen8_disasm.c',
> + 'gen8_instruction.c',
> + 'ralloc.c',
> +]

FWIW I like this style of assigning lists.

> +
> +lib_brw = shared_library('brw', lib_brw_src,
> + dependencies : igt_deps)

The Emacs meson mode nicely indents the continuation lines after the
opening (. These seem off... all over the place.

> +
> +flex = find_program('flex')
> +bison = find_program('bison')
> +
> +lgen = generator(flex,
> + output : '@BASENAME@.c',
> + arguments : ['-o', '@OUTPUT@', '@INPUT@'])
> +
> +lfiles = lgen.process('lex.l')
> +
> +pgen = generator(bison,
> + output : ['@BASENAME@.c', '@BASENAME@.h'],
> + arguments : ['@INPUT@', '--defines=@OUTPUT1@', 
> '--output=@OUTPUT0@'])
> +
> +pfiles = pgen.process('gram.y')
> +
> +executable('intel-gen4asm', 'main.c', lfiles, pfiles, link_with : lib_brw)
> +
> +executable('intel-gen4disasm', 'disasm-main.c', link_with : lib_brw)
> +
> +gen4asm_testcases = [
> + 'test/mov',
> + 'test/frc',
> + 'test/rndd',
> + 'test/rndu',
> + 'test/rnde',
> + 'test/rnde-intsrc',
> + 'test/rndz',
> + 'test/lzd',
> + 'test/not',
> + 'test/immediate',
> +]
> +
> +# Those tests were already failing when the assembler was imported from
> +# the intel-gen4asm git repository:
> +#   http://cgit.freedesktop.org/xorg/app/intel-gen4asm/
> +# We disable them "for now" as a workaround to be able to release i-g-t
> +gen4asm_testcases_broken = [
> + 'test/declare',
> + 'test/jmpi',
> + 'test/if',
> + 'test/iff',
> + 'test/while',
> + 'test/else',
> + 'test/break',
> + 'test/cont',
> + 'test/halt',
> + 'test/wait',
> + 'test/endif',
> +]
> +
> +test_runner = find_program('test/run-test.sh')
> +foreach testcase : gen4asm_testcases
> + test('assembler: ' + testcase, test_runner,
> + args : testcase,
> +