mir/libreoffice
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
libreoffice/config_host/config_clang.h.in

21 lines
358 B
C
Raw Normal View History

config_clang.h
2012-12-23 22:38:34 +01:00
/*
Settings related to Clang compiler plugins.
*/
#ifndef CONFIG_CLANG_H
#define CONFIG_CLANG_H
better handling of which files are processed by clang plugins Check that only LO's files are processed, as there's no point otherwise. Also warn about files in workdir/solver/builddir, as those are either generated or copies. Try to automatically match include files from solver to srcdir though, as that's where include files are usually included from :(. Change-Id: Ie8389e903f623a9d0e75015091acc0da78e76c3a
2013-01-03 20:15:21 +01:00
#undef BUILDDIR
config_clang.h
2012-12-23 22:38:34 +01:00
#undef SRCDIR
better handling of which files are processed by clang plugins Check that only LO's files are processed, as there's no point otherwise. Also warn about files in workdir/solver/builddir, as those are either generated or copies. Try to automatically match include files from solver to srcdir though, as that's where include files are usually included from :(. Change-Id: Ie8389e903f623a9d0e75015091acc0da78e76c3a
2013-01-03 20:15:21 +01:00
#undef WORKDIR
config_clang.h
2012-12-23 22:38:34 +01:00
These version checks are about the Clang the plugins are built /against/ ...not the (Clang) compiler they are being built /with/. (Also simplifies the checking #if code.) Change-Id: I416321be4ef4478785be40571f81500fd3b6feb8
2016-02-26 12:50:16 +01:00
#undef CLANG_VERSION
do not set our clang timestamp to the timestamp of the clang binary If the clang binary comes from a package which had been built before any of our clang related sources were changed the last time, the timestamp would be older and so there would be no rebuild. So do the stamp handling the usual way, clang upgrades will work fine, downgrades will not, but that's the same problem like with downgrading a library and its headers. To somewhat mitigate the problem (Clang plugin doesn't get cleaned by 'make clean'), include the full Clang version (which includes SVN revision) in config_clang.h and make all Clang plugin code include that, so at least configure re-run will trigger a rebuild if necessary. Change-Id: I993197f79e92e36105092c92c33b2e1db343e975
2013-01-06 18:09:04 +01:00
/* This is actually unused, but it should change whenever Clang changes,
Fix typos Change-Id: I90b04b8eda6fc3d530c9db72052720cbe9de0343 Reviewed-on: https://gerrit.libreoffice.org/21197 Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> Tested-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2016-01-04 12:44:22 +01:00
thus causing update of this .h file and triggering rebuild of our Clang plugin. */
do not set our clang timestamp to the timestamp of the clang binary If the clang binary comes from a package which had been built before any of our clang related sources were changed the last time, the timestamp would be older and so there would be no rebuild. So do the stamp handling the usual way, clang upgrades will work fine, downgrades will not, but that's the same problem like with downgrading a library and its headers. To somewhat mitigate the problem (Clang plugin doesn't get cleaned by 'make clean'), include the full Clang version (which includes SVN revision) in config_clang.h and make all Clang plugin code include that, so at least configure re-run will trigger a rebuild if necessary. Change-Id: I993197f79e92e36105092c92c33b2e1db343e975
2013-01-06 18:09:04 +01:00
#undef CLANG_FULL_VERSION
config_clang.h
2012-12-23 22:38:34 +01:00
#endif
Reference in New Issue Copy Permalink