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 <sthibault@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
Context
Privacy Policy |
Impressum (Legal Info) |
Copyright information: Unless otherwise specified, all text and images
on this website are licensed under the
Creative Commons Attribution-Share Alike 3.0 License.
This does not include the source code of LibreOffice, which is
licensed under the Mozilla Public License (
MPLv2).
"LibreOffice" and "The Document Foundation" are
registered trademarks of their corresponding registered owners or are
in actual use as trademarks in one or more countries. Their respective
logos and icons are also subject to international copyright laws. Use
thereof is explained in our
trademark policy.