Hello, 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> 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. Samuel _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice