summaryrefslogtreecommitdiff
path: root/solenv/gbuild/ExternalProject.mk
AgeCommit message (Collapse)Author
2022-05-03Keep passing LDFLAGS into external proejct buildsStephan Bergmann
...which had been broken with 1ffd6897ddf15624e70585ab08e8af713114c938 "try to use also proper debug LDFLAGS for externals libraries", and e.g. one of my macOS builds uses a non-standard Clang compiler and libc++ library, and thus needs LDFLAGS=-L/Users/stephan/llvm/inst/lib in autogen.input Change-Id: Iae67a4a13603b0241e5cd6c0d01a07ac898ffb58 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133746 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-05-01try to use also proper debug LDFLAGS for externals librariesLuboš Luňák
This is basically ea68de2968c0dbcd8e7549435e829db06795c16d but for LDFLAGS. A number of external libs cannot use this because their libtool mishandles -fuse-ld. Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-12use gb_DEBUGINFO_FLAGS consistently in gbuild ExternalProject'sLuboš Luňák
A number of them didn't use it at all, others had it hand-written in various ways. Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-13set up gb_COMPILER_SETUP properly for gb_ExternalProject_runLuboš Luňák
If the command to run would be "cmd1 && cmd2", the old way would set up the variables only for the first command. Change-Id: I190bbf535eab4fb0191a87add2ec19e9a2f11e0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129878 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-13gbuild: implement static partial buildJan-Marek Glogowski
This stores all the dependencies collected from the full build, and uses that info to link static binaries in per module. Change-Id: I27bd41c217bf0d2248ee88004038dd6b813f2624 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128129 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-11-08set up gb_COMPILER_SETUP also for gbuild's ExternalProjectLuboš Luňák
It's used to set up various ccache variables, which without this aren't applied to builds handled by other build systems. Change-Id: Id1157b5a02d607651ba18b249375da6e1fa13cd8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124826 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-16Revert "Make font-based unit test depend on instdir fonts"Jan-Marek Glogowski
The following build: $ make clean && make gb_CppunitTest_sc_ucalc [...] $ cd sc $ make gb_CppunitTest_sc_ucalc triggers: sc/CppunitTest_sc_subsequent_filters_test.mk:133: *** Missing font filelist -> run make more_fonts extras. This didn't help the general Win32 font build problem AFAIK. There were additional patches to the way Windows loads the LO provided fonts, so just revert this. This reverts commit 368c996b24e09c427a30972b3405493328db6779. Change-Id: I841f96fe8312c47980c8e3be2e9d88242df5b28d Reviewed-on: https://gerrit.libreoffice.org/84633 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-07-05Make font-based unit test depend on instdir fontsJan-Marek Glogowski
The current dependency is already a hack, because there is no way I know of to depend on delivered top-level modules like more_fonts. The original patch parses the gb_Package_MODULE_ooo_fonts list of registered packages to add them as build dependencies. But this is not sufficient, as it just adds the dependencies on the installed / unpacked fonts in the workdir (actually it's just the installer filelist), where they can't be found by the unit test running in the instdir environment. So this converts the depndency into a make error, if either the filelist is missing or the included font files. But if we are in a full run and know the more_fonts module, we simply depend on its delivered files. This needs some minimal changes to gbuild, as neither the delivered file list nor the modules class names are yet available. And this moves the fontconfig handling to extras, where the opensymbol font is already handled. Change-Id: I1b70a4c45ff189266ce56c57e534ddc45e7c5c19 Reviewed-on: https://gerrit.libreoffice.org/74624 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2017-11-01gbuild: ExternalProject: improve NMAKE handlingMichael Stahl
- move actual variables into com_MSC_class.mk - use export ... && to set the variables, so they affect all subsequent commands, not just the first one - clear MAKE as well, as that is apparently used by nmake, but can only point to GNU make - set CC, because nmake apparently can interpret C:/Progra~1/.../cl.exe etc. etc. as a "C:" command with some additional arguments which only changes the current directory, without even invoking the shell, which tends to cause profanities to be uttered for extended periods of time Change-Id: Ia7b1e6a70d6ac116d4ef0312d2aa1a4747fb8cbf Reviewed-on: https://gerrit.libreoffice.org/44159 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Michael Stahl <mstahl@redhat.com>
2015-12-12Typo: strucure->structureJulien Nabet
Change-Id: I41e0731ddafc39ebcff1c3d8984f4f4f69d35aaf
2015-06-25restore gb_ExternalProject_use_unpacked, with diff. purposeDavid Tardon
Change-Id: I7d7cbe85219615f80069155a954f917781bc5b71
2014-11-18windows: msbuild gets completely confused when the 'Platform' envvar is set.Jan Holesovsky
Change-Id: Iea04859c6afa203bd6b527b99c680ff4176cf9e1
2014-11-12Fix common typos. No automatic tools. Handmade…Andrea Gelmini
Change-Id: I1ab4e23b0539f8d39974787f226e57a21f96e959 Reviewed-on: https://gerrit.libreoffice.org/12164 Reviewed-by: Noel Grandin <noelgrandin@gmail.com> Tested-by: Noel Grandin <noelgrandin@gmail.com>
2014-05-30rebuild ext. project if makefile changesDavid Tardon
Change-Id: Ib1b7dab5b4fa10f068bcce58e00450895c455121
2014-03-06Add apr and serf externals for alternative webdav implementation.Matúš Kukan
Change-Id: I5e93bb6fb53537b889c6ba9888f0f32a0d6f8050
2014-02-13gbuild: improve error messages about missing registrationsMichael Stahl
Change-Id: Ib3c5d8f3921801f143447d8e01463905d80ac319
2013-10-25jfreereport: use jar files from WORKDIRMichael Stahl
Change-Id: Ie3d706841faae40e6172ae36894f4ad700d70571
2013-10-25language tool: fix buildMichael Stahl
Change-Id: I6ba856d6817aa838a0519803eb5d8f582598c800
2013-10-25gbuild: add gb_ExternalProject_use_jarsMichael Stahl
Change-Id: Idd67548cb5f0e49e539459ed7f2fbd107d37c1b3
2013-07-19gbuild: add support for auto-creationa nd reuse of binary package.Norbert Thiebaud
many so-called 'external' libraries are built using the UnpackedTarball/ExternalProject pattern, and their build is quite stable... they can go month without any changes. Yet some buildbot, that need to do full build, build them over and over again. This patch introduce the infrastructure to shortcut these build by using a binary package of the build result Change-Id: Ib0daf2a9d1a1f76802273c093bae7df8da4a90f8 Reviewed-on: https://gerrit.libreoffice.org/4764 Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com> Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
2013-06-07gbuild: do not register static librariesMatúš Kukan
It does not make sense, there was only one group anyway. Change-Id: I606138ceed0bfc628b8a23abb864280d9626ed60
2013-05-07gbuild: ExternalProject: always build externals from scratchMichael Stahl
It could happen that externals were built incrementally, in case something the ExternalProject depends on was updated. To prevent this, change the dependencies so that the UnpackedTarball is unpacked again when the ExternalProject's dependencies are newer. This is possible without introducing a new target for the purpose due to the refactorings in previous commits that enforce the name of UnpackedTarball. Change-Id: Ie7a84064ec2ffc76175cd2b7792517e68664a461
2013-05-07gbuild: ExternalProject: remove second parameter again...Michael Stahl
... now that everything is consistent. Change-Id: I96c15159648815554280202eb1b6d274ead4e7b8
2013-05-07gbuild: remove gb_ExternalProject_use_unpackedMichael Stahl
It must always be used exactly once, so replace it with constructor parameter. Change-Id: Ifbe87065c19a5185a5705dc461656179002ece5d
2013-03-14gbuild: move MSC specific wrapper stuff to platform/Michael Stahl
That's where code conditional on COM or OS belongs. Change-Id: Id31378bcc840dc38aa4b64241f0d1ccc11a99792
2013-03-14cygpath only exists in Windows build, 2nd tryDavid Tardon
Avoid the $(shell cygpath) calls when not on windows. The error message is harmless, but it bothers me. I think gb_ExternalProject_use_autoconf (and the AUTOCONF_WRAPPERS definition) should be moved to gbuild/platform. Change-Id: Ia537c5dac682f93ce5efe5c54b97b3a257cb6136
2013-03-14cygpath only exists in Windows buildDavid Tardon
2013-03-14add gcc-wrapperPeter Foley
Change-Id: I961bd23d1ec382d247a489cda42194ce9f4fe1da Reviewed-on: https://gerrit.libreoffice.org/2715 Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org> Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
2013-02-22quiet external module build log unless failureNorbert Thiebaud
ExternalProject usually involve a configure and a make step that produce a bunch of output usually irrelevant including a large number of warning and other mess. now that everything is pretty much in tail_build these output get interleaved with useful output from the build of the product and actually drown them in a logorrhea of messy noise. This store the output of external modules in a log file and only print them as a whole if the module failed do build. on a non-verbose build. Change-Id: I3abfcccd6d16821a9e061a71e031b427cc283647 Reviewed-on: https://gerrit.libreoffice.org/2304 Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com> Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
2012-12-10userfriendly make targets for build and cleanLuboš Luňák
So that now it's possible to do just 'make CppunitTest_sw_macros_test' instead of 'make /home/llunak/build/src/l2/workdir/unxlngx6/CppunitTest/sw_macros_test.test' Change-Id: Ibd1e9ef4fc825043a71bd669b2f5c37ffec68e33 Reviewed-on: https://gerrit.libreoffice.org/1253 Reviewed-by: Peter Foley <jpfoley2@gmail.com> Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de> Reviewed-by: Luboš Luňák <l.lunak@suse.cz> Tested-by: Luboš Luňák <l.lunak@suse.cz>
2012-10-05gbuild: add gb_ExternalProject_use_external:Michael Stahl
Or rather, re-purpose that for consistency (and rename original to gb_ExternalProject_use_external_project), to abstract over the system/internal status of dependencies of external projects. Use it in libcdr and replace exisiting uses in apache-commons. Change-Id: Ie144600688fa884b5b6faa986c6b95bdfc1ee15c
2012-10-05gbuild: ExternalProject: add use_libraries, use_static_librariesMichael Stahl
Change-Id: Idc8b0adf1a9ed26b2e0bec3454fed0ee34e277aa
2012-10-05libcdr: argh i am getting senileMichael Stahl
Change-Id: I1674da35bf1d756bda5c4b991cc586462325c838
2012-10-05libcdr: hopefully get this to buildMichael Stahl
unfortunately the ExternalProject uses a StaticLibrary built in libwpg. Change-Id: Ie4a8933247edbd2d53f697432a0848a05216237f
2012-10-05gbuild: implement gb_ExternalProject_use_externalsMichael Stahl
Change-Id: Ie6eed251a5034d9761abca75506b677af394d945
2012-10-04add gb_ExternalProject_use_package(s)David Tardon
There needs to be a way to depend on the output of other external packages. Change-Id: Ic0f200b6d6b6c0968a28434ba96f1a2f1efa527e
2012-09-27add gb_ExternalProject_use_external to deal with ExternalProject inter-depNorbert Thiebaud
One may have multiple ExternalProject in a given module and these ExternalProject may have dependencies among each others This api allow to explicit such dependencies so that the ExternalProjects in a given module are built in the right order Change-Id: Ib8a1b9bdcad0dda08b6fe133113b01a80e02421c
2012-09-26Revert "gbuild: use one pattern rule for creating directories"Matúš Kukan
It does not work with make 3.82 which prefers pattern rules with longest match, so wrong rules are chosen in workdir. This reverts commit bc234b4e1103cf8f79a7526ad80dcd9d0b78b89b.
2012-09-26gbuild: use one pattern rule for creating directoriesMatúš Kukan
Change-Id: I0164552ea9f2024eb5c44ad3b2b6181f6a9e3a1e
2012-09-22add gbuild class ExternalPackageDavid Tardon
This should make delivering of header files (but other kinds of files too) from the unpacked tarballs more reliable with respect to project updates. Change-Id: Ic9dac800eddecedffba5f955f1e8d585da9c1b17
2012-08-24add support for building external projectsDavid Tardon
Change-Id: I1ae354e3bf85c29679919f6382e14d3e4232d798
generated by cgit (git 2.34.1) at 2025-02-05 16:05:28 +0000