summaryrefslogtreecommitdiff
path: root/solenv
AgeCommit message (Collapse)AuthorFilesLines
2018-02-19Buildsystem changes to recognize Haiku.Kacper Kasper3-0/+32
Change-Id: I219d556f8e124cfe426cc1ac3c54da34eb7ef790 Reviewed-on: https://gerrit.libreoffice.org/49925 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Tested-by: Jenkins <ci@libreoffice.org>
2018-02-18tdf#115554: Create tar archives using 'fakeroot'Michael Weghorn2-30/+17
'tar' must be run as root or faked to be run as root, to make sure that file ownerships and permissions inside the created tar archives are as desired (root:root). Have fakeroot take care about creating an appropriate environment rather than using the custom "libgetuid", to no longer have to care about tar internals by ourselves. This fixes the problem that file ownerships are incorrect when tar version >= 1.24 is used for * tar archives holding all the generated deb/rpm packages (created in 'download.pm') * tar archives created by using the '--with-pacakage-format=archive' autogen option (created in 'simplepackage.pm') Change-Id: Id20ccce4d002ff95c75292eda8080ca299eee3a5 Reviewed-on: https://gerrit.libreoffice.org/49682 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-02-18tdf#115554: Use 'fakeroot' to build Debian packagesMichael Weghorn1-15/+4
The command to create Debian packages must be run as root or faked to be run as root. The 'fakeroot' makes sure the command is run in an environment faking root privileges for file manipulation. This makes sure that file ownerships and permissions inside the created deb packages are correct. Using fakeroot instead of the custom "libgetuid" makes it unnecessary to care about internals of the underlying tools (like tar) and changes in those by ourselves. Change-Id: I2cbb203ab84f740377e535c1051c2b879779b164 Reviewed-on: https://gerrit.libreoffice.org/49597 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com> Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
2018-02-15Adapt solenv/flatpak-manifest.inStephan Bergmann1-3/+3
...to 45a4e70484e7d90dab07a677914ada2d948b415c "Update orcus to 0.13.3." Change-Id: I6a400b264b7ae0be73b55110a67617d0e5f3d3fa
2018-02-14Revert "--disable-pdfium for Linux aarch64 Flatpak build"Stephan Bergmann1-1/+1
...which should no longer be needed w/ 9efd288b31e259b964097d3eeeff7f6c10945cb3 "pdfium: disable custom allocator". (On Flathub, the original problem had been seen with worker gnome-aarch64-1 using 64K pages, but not with arm-1/arm-3 using 4K pages.) This reverts commit ffc134445ef7e935d18d816626f64e65b4cdbca6. Conflicts: solenv/flatpak-manifest.in Change-Id: I7d169ba92cdcd651b1c560aabf0d4559fad8cf9c
2018-02-12Work around i386 kernel vs. JVM bug for now by disabling all tests on i386Stephan Bergmann1-1/+1
<https://bugzilla.redhat.com/show_bug.cgi?id=1468436> "Libreoffice Writer crashing with segmentation fault in libjvm.so _expand_stack_to when wiki plugin installed" still hits various machines (e.g., my local 4.14.16-300.fc27.x86_64 as well as 3.10.0-693.11.6.el7.x86_64 flathub-builder-pdx1, see <https://flathub.org/builds/#/builders/3/builds/1790>), causing --arch=i386 builds to fail tests that instantiate a JVM in-process, e.g. CppunitTest_dbaccess_RowSetClones with SIGSEGV at > #0 _expand_stack_to (bottom=0xff605fff <error: Cannot access memory at address 0xff605fff>, bottom@entry=0xff605000 <error: Cannot access memory at address 0xff605000>) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:608 > #1 0xed207564 in os::Linux::manually_expand_stack (t=0x58314800, addr=0xff605000 <error: Cannot access memory at address 0xff605000>) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:621 > #2 0xed211d5b in os::create_attached_thread (thread=0x58314800) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:839 > #3 os::create_main_thread (thread=0x58314800) at /run/build/java/hotspot/src/os/linux/vm/os_linux.cpp:789 > #4 0xed36d8a7 in Thread::set_as_starting_thread (this=0x58314800) at /run/build/java/hotspot/src/share/vm/runtime/thread.cpp:941 > #5 Threads::create_vm (args=0xffdf0810, canTryAgain=0xffdf068f) at /run/build/java/hotspot/src/share/vm/runtime/thread.cpp:3614 > #6 0xecfc5081 in JNI_CreateJavaVM_inner (args=0xffdf0810, penv=0xffdf0a84, vm=0xffdf0798) at /run/build/java/hotspot/src/share/vm/prims/jni.cpp:3937 > #7 JNI_CreateJavaVM (vm=0xffdf0798, penv=0xffdf0a84, args=0xffdf0810) at /run/build/java/hotspot/src/share/vm/prims/jni.cpp:4032 > #8 0xf32b5397 in jfw_plugin_startJavaVirtualMachine(JavaInfo const*, JavaVMOption const*, long, JavaVM_**, JNIEnv_**) () from /run/build/libreoffice/instdir/program/libjvmfwklo.so ... Disabling tests leads to successful builds, but using Java functionality in the LO flatpak on affected machines (where the above bug or similar for other Linux distros is not yet fixed) will still crash, of course. Users of the LO flatpak will need to seek a fixed kernel (or there will need to be an update of org.freedesktop.Sdk.Extension.openjdk9 and a rebuild of the LO flatpak, if it turns out that a fix will need to be applied to OpenJDK instead of the kernel). This workaround can be removed again once no Flathub build machines are affected by the bug any longer. (`uname -i`, reporting "i386", appears to be more appropriate for this check than `uname -m`, which might probably report other tokens besides "i686".) Change-Id: I6e4b01d1df5aff5ac31847fd56285506af003f4b
2018-02-12Include <release> in Flatpak appdata.xmlStephan Bergmann1-1/+6
...fixing <https://github.com/flathub/org.libreoffice.LibreOffice/issues/13> "No version information". This is only minimal release information (cf. <https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html# tag-releases>), but is what is available directly in the build without additional manual input. Lack of either a date or timestamp attribute causes a failure "org.libreoffice.LibreOffice.desktop: AppData problem: attribute-missing : <release> has no timestamp", so include the current date in ISO 8601 format to silence that. It is assumed that the LIBO_VERSION_* variables will only contain numeric values, so don't need to be encoded when included in an XML attribute. Change-Id: I442a01d5093ab2621897685c3bc1eeda4ee08fa9
2018-02-12solenv: document how to build static clang-formatMiklos Vajna1-2/+2
Change-Id: Ibadb8966f1c3ba7e241b9eb5d36c9067f0246c86
2018-02-09Adapt solenv/flatpak-manifest.inStephan Bergmann1-3/+3
...to e13acfcac9571da7efeec8fe5b27b11249d51c27 "Update liborcus to 0.13.2." Change-Id: I5e2b8d9ea4f91571fe884944a6c0a390d650993f
2018-02-09solenv/flatpak-manifest.in: Merge in building with GCC 7Stephan Bergmann1-0/+16
This merges in * <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ d1ca6fbdac7f0adcfd813ac5556d6ad979924232> "switch to gcc7", * <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 687e79514c12bb8c6fd7dfd93f1e4fb84fc6af54> "Copy org.freedesktop.Sdk.Extension.gcc7 libs into app", and * <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ 41b361bf4973b0981f834fe58b3f808b0ca81634> "Use `cp -d` to preserve symlinks", which should allow to build on 32-bit arm once <https://github.com/flathub/org.freedesktop.Sdk.Extension.openjdk9/issues/4> "ARM version" is fixed. Those had been reverted again on flathub with <https://github.com/flathub/ org.libreoffice.LibreOffice/commit/1168072d19f358ffacc783aa83773789c6eafb99> "Revert 'Gcc7' again, for now" because it had apeared back then that using GCC 7 caused the build to fail on aarch64. This has meanwhile been tracked down to be an issue with PDFium instead, see ffc134445ef7e935d18d816626f64e65b4cdbca6 "--disable-pdfium for Linux aarch64 Flatpak build". Change-Id: I594d38ecfdf7dbd78b91af04b9f3f3e86987b8e5
2018-02-09--disable-pdfium for Linux aarch64 Flatpak buildStephan Bergmann1-1/+1
At least current PDFium master <https://pdfium.googlesource.com/pdfium/+/ 026717cb667cf0c7215cf55daf794d69752fc900/third_party/base/allocator/ partition_allocator/page_allocator.h#33> still hard-codes the assumption that "All Blink-supported systems have 4096 sized system pages". On Linux aarch64 machines with 64K page size (as reported by `getconf PAGE_SIZE`, e.g., on Flathub worker <https://flathub.org/builds/#/workers/18> "gnome-aarch64-1"), that causes LO's CppunitTest_svtools_graphic to fail with SIGABRT, when pdfium::base::SetSystemPagesInaccessible (workdir/UnpackedTarball/pdfium/ third_party/base/allocator/partition_allocator/page_allocator.cpp) causes an mprotect to fail in a pattern like > mmap(0x1051200000, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x1051200000 > mprotect(0x1051200000, 4096, PROT_NONE) = 0 > mprotect(0x1051202000, 8192, PROT_NONE) = -1 EINVAL (Invalid argument) The loss of functionality caused by --disable-pdfium is assumed to be acceptable ("used for insert->image and selecting a pdf I believe", according to caolan on IRC), and e.g. Fedora disables it for all arches since <https://src.fedoraproject.org/rpms/libreoffice/c/ 1f6713e951de6aa9af43a9bd92ed011edf0c6fe9> "update to 5.4.0 alpha1". Change-Id: I39385c332ddd6a2a3a221f0d0577181709944313
2018-02-09solenv/flatpak-manifest.in: Disable debug information again, for nowStephan Bergmann1-1/+1
Merge in <https://github.com/flathub/org.libreoffice.LibreOffice/commit/ c6831b215070415a32669fbe63adfc4c36b5f568> "Disable debug information again, for now", to bring repos back in sync. If we want to keep this permanently, --enable-symbols should instead be dropped from distro-configs/LibreOfficeFlatpak.conf. Change-Id: I656d77a446deecbc41ab25f05af7187dc544126c
2018-02-09Use sha256 instead of sha512Stephan Bergmann1-1/+1
...as the latter is apparently a recent addition to flatpak-manifest that some Flathub workers (like <https://flathub.org/builds/#/workers/16> "arm-3") still do not support, causing "module libreoffice: Sha256 not specified" failures. <http://ant.apache.org/bindownload.cgi> and <https://archive.apache.org/dist/ant/binaries/> do not provide SHA-256 values, so computed it locally. Change-Id: Iee664402f26c9ab428624a4a7933db310efd71b1
2018-02-09Use stable URL for apache-ant downloadStephan Bergmann1-1/+1
as proposed by <http://mail-archives.apache.org/mod_mbox/ant-user/201802.mbox/ %3c001b01d3a101$eadd7ea0$c0987be0$@de%3e> "AW: Stable link to apache-ant-*-bin.tar.xz?" (but using https instead of http) Change-Id: I6f1a5d06c4f2f6ad1861a5c0bda3341f13c8899a
2018-02-09clang-format: improve error message when CI failsMiklos Vajna1-1/+4
Don't just tell the problem but hint how to fix it. Change-Id: I9d079ee7d4ed61266e22a3fa21efe10366724645 Reviewed-on: https://gerrit.libreoffice.org/49471 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-02-09Remove dead Executable_genlangStephan Bergmann1-27/+0
...originally introduce with 999c68f12f1d95b16a97294949a0e6ba6d3ba259 "genLang project (awareness)", but apparently never took off. Change-Id: I6f61271a75d96750dea63de596b7745c2f589b83 Reviewed-on: https://gerrit.libreoffice.org/49389 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-02-08Adapt solenv/flatpak-manifest.in to apache-ant-1.10.2Stephan Bergmann1-2/+2
...that apparently made the URL for apache-ant-1.10.1 become 404. (Again, the sha512 for the new version is as given at <http://ant.apache.org/bindownload.cgi>.) (Asked at <http://mail-archives.apache.org/mod_mbox/ant-user/201802.mbox/ %3C039da509-898d-53f5-4c35-ecfa6b6bef18%40redhat.com%3E> "Stable link to apache-ant-*-bin.tar.xz?" whether there's any better link that I could use, to avoid having to constantly track the latest revision of Ant here.) Change-Id: Ic13732d172ade9337f006d4495f066fdd52302a1
2018-02-08fix oss-fuzz buildCaolán McNamara1-2/+2
Change-Id: I9ca03f1b39906cc416e77fe74a07bda04388f166
2018-02-08xmlsecurity: fold Library_xsec_fw into Library_xmlsecurityMiklos Vajna1-2/+0
That little amount of code hardly justifies a separate library. Change-Id: Idbb039f38258bc12759fcf6d29328e1afe7443ab Reviewed-on: https://gerrit.libreoffice.org/49391 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-02-07solenv: adapt native-code.py to recent xmlsecurity changesMiklos Vajna1-1/+3
/tmp/native-code-95f2b3.o:native-code.cxx:lo_get_factory_map::map: error: undefined reference to 'xmlsecurity_component_getFactory' clang++: error: linker command failed with exit code 1 (use -v to see invocation) ../Bootstrap/Makefile.shared:61: recipe for target 'obj/local/armeabi-v7a/liblo-native-code.so' failed make[2]: *** [obj/local/armeabi-v7a/liblo-native-code.so] Error 1 /home/vmiklos/git/libreoffice/master-android/android/CustomTarget_lo_android.mk:17: recipe for target '/home/vmiklos/git/libreoffice/master-android/workdir/CustomTarget/android/source/done' failed Change-Id: Idd63986122216c0fb1822ea7a3fbec00d00b444b
2018-02-04xmlsecurity: create DocumentDigitalSignatures instances with a constructorMiklos Vajna1-22/+0
Change-Id: I9780438c3b7f8206fad3bfe29e93d1fcf535b811 Reviewed-on: https://gerrit.libreoffice.org/49199 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
2018-02-04gbuild-to-json: unblacklist extensionsMike Kaganski1-1/+1
Change-Id: I6accb1b363804a2935c92d471f7baff31771b5a0 Reviewed-on: https://gerrit.libreoffice.org/49202 Reviewed-by: jan iversen <jani@libreoffice.org> Tested-by: jan iversen <jani@libreoffice.org>
2018-02-01Fix typosAndrea Gelmini1-1/+1
Change-Id: I5cfa53bbe82fc3611770fdbe3b58d593f7a7c89f Reviewed-on: https://gerrit.libreoffice.org/49100 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Michael Stahl <mstahl@redhat.com>
2018-02-01deps w/ hardlinks: don't create it as foo_ only to move it to fooChristian Lohmaier1-0/+10
this breaks with CCACHE_HARDLINK=1 on close-enough rebuilds, as there will be "foo" from previous run (hardlinked to ccache-dir), and foo_ will be hardlink to the same file, resulting in mv to barf out since foo_ and foo are the same file (and -f/force doesn't help in this case) Change-Id: Iaefcec05b34dad88f49477693e2157c1ca0623ac Reviewed-on: https://gerrit.libreoffice.org/42586 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-01-30Don't let PythonTest_solenv_python fail due to Emacs lock files in SRCDIRStephan Bergmann1-1/+3
Emacs has a habit of placing lock files next to files being edited, which are actually dangling symlinks not pointing at actual files, but where the symlink content itself encodes some information about who locked the file. When such a lock file happens to be present in the source tree during `make PythonTest_solenv_python`, the latter fails because shutil.copytree by default copies files pointed at by symlinks, instead of the symlinks themselves, and causes an error if that fails. An alternative fix would be to call shutil.copytree with symlinks=true (copy symlinks, not the files pointed at) or ignore_dangling_symlinks=true (don't fail if a dangling symlink can't be copied). But for now just don't copy any of those additional files that Emacs likes to place next to edited files (and which are also all ignored in our .gitignore). Change-Id: Ib731a5395fe8d40767878c17b1fb422b914bb329 Reviewed-on: https://gerrit.libreoffice.org/48898 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-24Natvis: update SfxItemSet visualizer (m_pItems is now unique_ptr)Mike Kaganski1-1/+1
Change-Id: I862f6399a9a065ef725211b44f77400927db9a8f Reviewed-on: https://gerrit.libreoffice.org/48496 Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Mike Kaganski <mike.kaganski@collabora.com>
2018-01-24Adapt solenv/flatpak-manifest.inStephan Bergmann1-3/+3
...to e1026e267b4b1b0b0bd645c6bc212d6fa71544f8 "pdfium: update to 3312" Change-Id: I319b00d13d8657849967e08e605d6428f30c5c2e
2018-01-24Globally disable -Wcast-function-type new with upcoming GCC 8Stephan Bergmann1-0/+7
...which unhelpfully even warns on reinterpret_cast, so causes failures like > [CXX] sal/osl/unx/signal.cxx > sal/osl/unx/signal.cxx: In function ‘bool onInitSignal()’: > sal/osl/unx/signal.cxx:267:50: error: cast between incompatible function types from ‘void (*)(int, siginfo_t*, void*)’ to ‘{anonymous}::Handler1’ {aka ‘void (*)(int)’} [-Werror=cast-function-type] > oact.sa_sigaction); > ^ And since all incompatible (but deliberate) casts between function types across our code base should already be written as reinterpret_cast, we shouldn't lose much by just disabling this new warning globally. Change-Id: If15e9606e8fdc676b61012e31d7369653951ceca Reviewed-on: https://gerrit.libreoffice.org/48431 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-23new loplugin: pointerboolNoel Grandin1-0/+1
look for possibly bogus implicit conversions to bool when passing (normally pointer) args to bool params. this plugin comes in the wake of a couple of bugs caused by refactoring, where some of the call sites were not currently updated. Of the changes, the following are real bugs: desktop/../dp_persmap.cxx StartInputFieldDlg in sw/../fldmgr.cxx which occurred as a result of commit 39d719a80d8c87856c84e3ecd569d45fa6f8a30e Date: Tue May 3 11:39:37 2016 +0200 tdf#99529 sw: don't pop up input field dialog before inserting field CSerializationURLEncoded::encode_and_append in forms/../serialization_urlencoded.cxx XclExpCFImpl::XclExpCFImpl in sc/../xecontent.cxx I have no idea how to properly fix this, just made a guess. SwDocTest::test64kPageDescs in sw/qa/core/uwriter.cxx which looks like a simple copy/paste error. Change-Id: I795ebd5ef485a1d36863dc27fe13832989f5a441 Reviewed-on: https://gerrit.libreoffice.org/48291 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Tested-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-22gbuild: always compile as C++17 with MSVC 2017Michael Stahl1-0/+3
The current update MSVC 2017.5 supports fancy new C++ features, but unfortunately in its default C++14 mode it falls over and dies with an internal compiler error as soon as it sees the WeakImplHelper variadic template. In order to work around the ICE, build everything as C++17, which somehow doesn't crash. This causes loads of deprecation warnings about obsolete std::this and badly designed std::that, almost all of them from boost headers, which are well known for following every best practice in the C++ book. Liberally sprinkle macros around to suppress the warnings for now, like we already do with the other million warnings from boost headers. Change-Id: Ia6b6ef5e457b5fe3c8cfe361ba5da39376bb7c4c Reviewed-on: https://gerrit.libreoffice.org/48225 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-01-22update flatpak-manifestDavid Tardon1-3/+3
Change-Id: If97c2f8826cbbd83821d9211040f1857e1a1e17f
2018-01-22boost: upgrade to release 1.66.0Michael Stahl1-0/+5
This claims to support Visual Studio 2017.4, but not the current 2017.5. * remove boost.auto_link.patch; it does not apply; not sure why we need this if we can just define BOOST_ALL_NO_LIB (see commit 7f2e168421c3cd928a31a52a8b5afe97e931d3ba) * remove some hunks from clang-cl.patch.0 that look fixed upstream * add a global workaround for spurious GCC warning: oox/source/drawingml/shape.cxx:921:54: error: ‘oShadowColor.boost::optional_detail::tc_optional_base<int>::m_storage’ may be used uninitialized in this function [-Werror=maybe-uninitialized] aFormat.Color = *oShadowColor; Change-Id: I1eb1d8b66554a84a7d7269f1faaa98695fe2f501 Reviewed-on: https://gerrit.libreoffice.org/48187 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2018-01-19gbuild: disable gb_COLOR on WNT for nowMichael Stahl1-0/+3
The Cygwin terminal swallows colorful error messages, which is unhelpful. Change-Id: I2005994eb76fdba1dc49efc2988e38ac460d6724
2018-01-19new loplugin:emptyifNoel Grandin1-0/+1
Change-Id: I1092115a0ceb3a5e6680a4b724b129f98a892c42 Reviewed-on: https://gerrit.libreoffice.org/48128 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2018-01-19Fix typosAndrea Gelmini1-1/+1
Change-Id: Icadf5cb88024b8889d49dc9c5210d0de8deaed3b Reviewed-on: https://gerrit.libreoffice.org/48172 Reviewed-by: Julien Nabet <serval2412@yahoo.fr> Tested-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-18android: use unified headers and llvm-c++ STL (x86) with NDK 16Christian Lohmaier2-7/+17
gnustl (and others) are to be removed in future versions of the ndk also bump gradle and build-tools to current versions along with it arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix that later Change-Id: Ic794c3293b599b77ec48096bf3283a99c09cbb79 Reviewed-on: https://gerrit.libreoffice.org/45163 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2018-01-18clang-format: allow just listing formatted filesMiklos Vajna1-2/+16
Without running clang-format on them. Also format one file at a time, so we don't run into command line length limits as the number of formatted files grows. Change-Id: Ie559d566db784e04965678f056dcb81cefe95378 Reviewed-on: https://gerrit.libreoffice.org/48085 Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk> Tested-by: Jenkins <ci@libreoffice.org>
2018-01-14Fix typosAndrea Gelmini1-1/+1
Change-Id: Icc5fc590a6a90e30afa5f61028d4dd0279fbe120 Reviewed-on: https://gerrit.libreoffice.org/47861 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2018-01-14Save full file path to pot filesGabor Kelemen2-2/+2
As requested here: http://nabble.documentfoundation.org/libreoffice-l10n-Pootle-source-file-paths-not-available-anymore-td4229127.html This adds the full source file path in case of .hrc and .ui files to the generated pot, relatie to srcdir. So instead of personalization.hrc:31 we can have cui/inc/personalization.hrc:31 for better context for translators. Since this is only in comment this will not change the translated status of strings. TODO: the other file formats we use are not affected by this. Change-Id: Id436d66698c93e07c46bf9c20601c5b480eadd0b Reviewed-on: https://gerrit.libreoffice.org/46591 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2018-01-12Enable loplugin:cstylecast for some more casesStephan Bergmann1-0/+1
...mostly of C-style casts among arithmetic types, and automatically rewrite those into either static_cast or a functional cast (which should have identical semantics, but where the latter probably looks better for simple cases like casting a literal to a specific type, as in "sal_Int32(0)" vs. "static_cast<sal_Int32>(0)"). The main benefit of reducing the amount of C-style casts across the code base further is so that other plugins (that have not been taught about the complex semantics of C-style cast) can pick those up (cf. the various recent "loplugin:redundantcast" commits, which address those findings after this improved loplugin:cstylecast has been run). Also, I found some places where a C-style cast has probably been applied only to the first part of a larger expression in error (because it's easy to forget parentheses in cases like "(sal_uInt16)VOPT_CLIPMARKS+1"); I'll follow up on those individually. The improved loplugin:cstylecast is careful to output either "(performs: static_cast)" or "(performs: functional cast)", so that compilerplugins/clang/test/cstylecast.cxx can check that the plugin would automatically rewrite to one or the other form. To allow fully-automatic rewriting, this also required loplugin:unnecessaryparen to become a rewriting plugin, at least for the parens-around-cast case (where "((foo)bar)" first gets rewritten to "(static_cast<foo>(bar))", then to "static_cast<foo>(bar)". Rewriting could probably be added to other cases of loplugin:unnecessaryparen in the future, too. (The final version of this patch would even have been able to cope with 361dd2576a09fbda83f3ce9a26ecb590c38f74e3 "Replace some C-style casts in ugly macros with static_cast", so that manual change would not have been necessary after all.) Change-Id: Icd7e319cc38eb58262fcbf7643d177ac9ea0220a Reviewed-on: https://gerrit.libreoffice.org/47798 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-12Support `make SdiTarget_...`Stephan Bergmann1-0/+1
Change-Id: I23dc4511a6f9f962adc8436ceb1a5b24823fb8e5 Reviewed-on: https://gerrit.libreoffice.org/47788 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-10gbuild: print a better error message when adding non-existing ModuleMichael Stahl1-1/+6
A confusing message "Corrupted module target stack!" is printed because: "If an included makefile cannot be found in any of these directories, a warning message is generated, but it is not an immediately fatal error; processing of the makefile containing the include continues. Once it has finished reading makefiles, make will try to remake any that are out of date or don’t exist." Change-Id: Ia728c0283885fe839dbf8dd8ae2a885230f23836 Reviewed-on: https://gerrit.libreoffice.org/47701 Reviewed-by: Michael Stahl <mstahl@redhat.com> Tested-by: Jenkins <ci@libreoffice.org>
2018-01-09upload libpagemaker 0.0.4David Tardon1-3/+3
Change-Id: Idc4b7eaa3331ee3831f7d27ca66663e23c30b8c9 Reviewed-on: https://gerrit.libreoffice.org/47615 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2018-01-08Let flatpak-builder build .Debug extensionStephan Bergmann2-2/+2
Includes a revert of 58891d589bd8da700f135b098dd50833277c65dc "Add distro-pack- install-strip target to be used by dev-tools' flatpak/build.sh". Change-Id: Ie2ba18bc13471b46e8d5f41868bae5aee17ff25f Reviewed-on: https://gerrit.libreoffice.org/47599 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-01-08gcc-wrappers: always pass -debug to linkerMichael Stahl1-1/+2
... like gbuild does; this causes a PDB file to be created, which is required by BinScope. Stops complaints about firebird's DLLs, which are apparently the only DLLs linked with gcc-wrapper. Change-Id: Ibe0e8053e0556748b1562b5f50f08480b2f2f89b
2018-01-08gcc-wrappers: recognise -ggdb.* in addition to -g as debug flagMichael Stahl1-1/+1
Firebird uses -ggdb. This causes it to have 2 PDB files, however this isn't sufficient to make BinScope happy, more investigation needed. Change-Id: I5286964586eaffea36790ab7a7ca2df75d85f068
2018-01-08gbuild: MSVC: invoke MSASM with /safesehMichael Stahl1-1/+1
BinScope complains that the sblo.dll lacks SAFESEH flag. Change-Id: If2b4b6592eac37542c3e2745d90a8e432b8da2e2
2018-01-06upload libabw 0.1.2David Tardon1-3/+3
Change-Id: I972ff9e0dbb73f6a38c886e1acd03cc4d62da2ec Reviewed-on: https://gerrit.libreoffice.org/47251 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2018-01-05upload libe-book 0.1.3David Tardon1-3/+3
Change-Id: I8862e7f4d2dcb007295028b9ec7be04e58ebafd3 Reviewed-on: https://gerrit.libreoffice.org/47264 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: David Tardon <dtardon@redhat.com>
2018-01-05remove dead eeitemid.hxxNoel Grandin1-1/+0
and inline the couple of constants still in use from it Change-Id: Icb9f5690b5649140bc0503a8917e6a0f764e3d9c Reviewed-on: https://gerrit.libreoffice.org/47404 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
generated by cgit v1.2.3 (git 2.39.1) at 2024-04-30 19:57:06 +0000