[Libreoffice-commits] core.git: bin/gla11y config_host.mk.in configure.ac solenv/gbuild
Stephan Bergmann
sbergman at redhat.com
Thu Feb 22 15:43:37 UTC 2018
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.)
More information about the LibreOffice
mailing list