Age | Commit message (Collapse) | Author |
|
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>
|
|
- 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>
|
|
Change-Id: I41e0731ddafc39ebcff1c3d8984f4f4f69d35aaf
|
|
Change-Id: I7d7cbe85219615f80069155a954f917781bc5b71
|
|
Change-Id: Iea04859c6afa203bd6b527b99c680ff4176cf9e1
|
|
Change-Id: I1ab4e23b0539f8d39974787f226e57a21f96e959
Reviewed-on: https://gerrit.libreoffice.org/12164
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
|
|
Change-Id: Ib1b7dab5b4fa10f068bcce58e00450895c455121
|
|
Change-Id: I5e93bb6fb53537b889c6ba9888f0f32a0d6f8050
|
|
Change-Id: Ib3c5d8f3921801f143447d8e01463905d80ac319
|
|
Change-Id: Ie3d706841faae40e6172ae36894f4ad700d70571
|
|
Change-Id: I6ba856d6817aa838a0519803eb5d8f582598c800
|
|
Change-Id: Idd67548cb5f0e49e539459ed7f2fbd107d37c1b3
|
|
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>
|
|
It does not make sense, there was only one group anyway.
Change-Id: I606138ceed0bfc628b8a23abb864280d9626ed60
|
|
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
|
|
... now that everything is consistent.
Change-Id: I96c15159648815554280202eb1b6d274ead4e7b8
|
|
It must always be used exactly once, so replace it with constructor
parameter.
Change-Id: Ifbe87065c19a5185a5705dc461656179002ece5d
|
|
That's where code conditional on COM or OS belongs.
Change-Id: Id31378bcc840dc38aa4b64241f0d1ccc11a99792
|
|
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
|
|
|
|
Change-Id: I961bd23d1ec382d247a489cda42194ce9f4fe1da
Reviewed-on: https://gerrit.libreoffice.org/2715
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
|
|
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>
|
|
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>
|
|
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
|
|
Change-Id: Idc8b0adf1a9ed26b2e0bec3454fed0ee34e277aa
|
|
Change-Id: I1674da35bf1d756bda5c4b991cc586462325c838
|
|
unfortunately the ExternalProject uses a StaticLibrary built in libwpg.
Change-Id: Ie4a8933247edbd2d53f697432a0848a05216237f
|
|
Change-Id: Ie6eed251a5034d9761abca75506b677af394d945
|
|
There needs to be a way to depend on the output of other external
packages.
Change-Id: Ic0f200b6d6b6c0968a28434ba96f1a2f1efa527e
|
|
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
|
|
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.
|
|
Change-Id: I0164552ea9f2024eb5c44ad3b2b6181f6a9e3a1e
|
|
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
|
|
Change-Id: I1ae354e3bf85c29679919f6382e14d3e4232d798
|