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 <sthiba...@hypra.fr> 
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

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.)
LibreOffice mailing list

Reply via email to