Invoking gla11y [was: core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild]

[Samuel Thibault]

Stephan Bergmann, on jeu. 22 févr. 2018 16:43:37 +0100, wrote:
> On 22.02.2018 13:54, Samuel Thibault wrote:
> > Miklos Vajna, on jeu. 22 févr. 2018 09:53:43 +0100, wrote:
> > > On Wed, Feb 21, 2018 at 10:11:18AM +0100, Samuel Thibault <sthibault at hypra.fr> wrote:
> > > > Rene Engelhard, on mer. 21 févr. 2018 10:02:08 +0100, wrote:
> > > > > OK, thanks - and then I wonder why this is ran in "normal" UIConfig targets and
> > > > > not only in make check...
> > > > For the "error" cases (-W none), it makes sense:
> > > > 
> > > > « Add to the build process error checking (only the hard errors such as
> > > > bogus target names). »
> > > > 
> > > > That's really the kind of issues one should get as soon as compilation
> > > > time.
> > > > 
> > > > Later on I'll add a call in "make check" time for the warnings.
> > > 
> > > For source code we have warnings for these linter type problems
> > 
> > Err, these are not just "linter type problems". They are undefined
> > references, just like undefined C references. So the failure belongs to
> > compilation time. If somebody modifies a .ui file in a way that gets
> > such undefined reference, compilation itself should really fail, just
> > like it does when a variable defintion is missing.
> > 
> > The "make check" warnings I mentioned above are *other* kinds of issues,
> > which would indeed only be tested within make check, made warnings by
> > default, and turned into errors by Jenkins.
> 
> I don't understand the "turned into errors by Jenkins" part.  How would that
> be done?
> 
> (And `make check` should ideally be "silent".  We do not want it to produce
> any non-fatal warnings.)

Well, perhaps I didn't understand what Miklos meant, then.

Miklos Vajna, on jeu. 22 févr. 2018 09:53:43 +0100, wrote:
> For source code we have warnings for these linter type problems and then
> --enable-werror (Jenkins uses it) turns those warnings into errors.
> 
> Probably the best would be if the .ui checker would follow the same
> pattern, instead of running it twice during 'make check' (which is a
> superset of 'make').

What I had understood from that was that at "make" time there are only
compiler errors, and at "make check" time there are linter warnings, and
in Jenkins, --enable-werror is used to turn these warnings into errors.

Now that I re-read it with what you said, I understand that

- at "make" time there are some compiler warnings which are turned into
errors in Jenkins with --enable-werror
- Miklos suggested that we only call gla11y at "make" time, and not a
second time at "make check" time.

I'm fine with emitting accessibility warnings at "make" time and let
Jenkins turning them into errors, I just thought from the discussions at
FOSDEM that they should be done at "make check" time.

Samuel