Consistently only assign something to $clang_format if it's a good
version, and also consistently return undef if we found no good version.
Change-Id: Iadbbb56a5c15dfaeec5c80e3cc8fcc78b787c04b
Reviewed-on: https://gerrit.libreoffice.org/46489
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
09:28 <@sberg> vmiklos, I think I ran into a scenario last night where I had
both `git add`-ed and non-added changes in a non-blacklisted file, and the
non-added changes violated clang-format (and the added ones did not), and the
commit hook complained
So make sure we validate the index version, not the filesystem one.
(And modify a formatted file to trigger CI validation of the hook change
itself.)
Change-Id: I6431b35ac50dd03741104b5709c5195d6ff28632
Reviewed-on: https://gerrit.libreoffice.org/46368
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
translations.git failed with "Can't locate ClangFormat.pm in @INC (you
may need to install the ClangFormat module)".
Change-Id: Ibbe051c1cb4c1200da58821589b8271434b1f9a6
Reviewed-on: https://gerrit.libreoffice.org/45020
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
- factor out common code to a shared module, and quote path to the
clang-format binary, just in case.
- add a new check-last-commit script that is the CI equivalent of the
exiting git pre-commit hook, but this one handles lack of clang-format
as an error, not as a warning.
- $LODE_HOME/opt/bin is supposed to be in PATH already, so not
mentioning LODE_HOME in ClangFormat::find() explicitly.
- if both COMPILER_PLUGINS and LODE_HOME is set, invoke
solenv/clang-format/check-last-commit as part of 'make check'
To test these changes as part of CI, fix a single style violation in an
already committed, non-blacklisted file.
This depends on the lode.git commit
496123bcae28e06c6d6aeda39a5afd1e1fb1fd98 (utils_Linux: install
clang-format in the Jenkins case, 2017-11-16), otherwise erroring out on
a not installed clang-format as part of the build would be a problem.
Change-Id: Ib3110826194ff78a7f1bed1c3796147e92ccb3ba
Reviewed-on: https://gerrit.libreoffice.org/44939
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Restrict the git hook further to only enforce style in case the found
clang-format binary's version matches to avoid output differences with
different clang-format version.
While at it, move the blacklist reading after the version check to speed
up committing a bit when no local enforcement happens.
Also add a simple script to list formatted files, since the blacklist is
large enough that doing it naively from the shell is too slow.
Change-Id: I0bc05961d262cc6bc91c6efdd1b91994ecfc6940
Reviewed-on: https://gerrit.libreoffice.org/44662
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Jenkins <ci@libreoffice.org>
- The actual blacklist has to be generated with
solenv/clang-format/generate-style-blacklist.sh in a separate commit.
- .clang-format is from
<https://lists.freedesktop.org/archives/libreoffice/2014-August/062802.html>,
except:
- the commented out lines are removed
- Standard is Cpp11 instead of Cpp03
- explicitly avoid sorting includes (requested during ESC meeting
2017-10-11)
- no indentation inside namespaces (lots of existing code in sc wants this)
- The git hooks prints a diff when the style is violated, along with a
command to fix up the violation automatically. It also enforces style
only in new files and ignores all files listed in the blacklist.
- To avoid introducing one more hard-to-setup build dependency for new
developers, help them two ways:
- if clang-format is not installed, provide pre-built binaries for
Linux/Windows/macOS
- download/install of these binaries are printed as cmdline
instructions, similar to how we have our own 'make' on Windows
- As per ESC call 2017-11-02, currently don't do any checks if
clang-format is not installed (as a first step).
Change-Id: Iaa139c396337e8734aa1853305d808438260c41a
Reviewed-on: https://gerrit.libreoffice.org/43736
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Miklos Vajna