Age | Commit message (Collapse) | Author |
|
This reverts
commit 2483cd198b51bd5d0819cbebf40f211b2ef1236d
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Fri Feb 11 19:40:36 2022 +0100
Correctly depend on source component file
and
commit 17ec55c48082254e1f55bcfa00808e45a50a9801
Author: Jan-Marek Glogowski <glogow@fbihome.de>
Date: Thu Jan 20 10:06:54 2022 +0100
Fail on non-optional, but filtered component names
because they cause failures on Windows builds that look
like:
warning: failed to load external entity "C:/cygwin/home/tdf/lode/jenkins/workspace/gerrit_windows@2/workdir/ComponentTarget/binaryurp/source/binaryurp.component"
cannot process C:/cygwin/home/tdf/lode/jenkins/workspace/gerrit_windows@2/workdir/ComponentTarget/binaryurp/source/binaryurp.component
Change-Id: Ia34cdabd76b47a6a4686ebd0f96ceb774d3236f2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129956
Tested-by: Jenkins
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
|
|
If any of the optional component lists contain a non-optional
component implementation, fail the component file generation and
show a diff of the offending component implementation name.
Change-Id: Ieac876e613f6945362186d4586dd2aacc5669920
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128645
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
|
|
No need for the older second copies in solenv/gbuild.
Change-Id: I088f7d06b0727d1b336e3ba314b5c874d8ce3776
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103027
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
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>
|
|
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>
|
|
Change-Id: I3424e17cfdfb563fdc5882942031deafae8689fe
Reviewed-on: https://gerrit.libreoffice.org/78678
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
Change-Id: Ic431ef6c3555f02fbc204a5b0af5f9bfe62f4a30
Reviewed-on: https://gerrit.libreoffice.org/77286
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
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>
|
|
Change-Id: I608f46235f2e80e74f6900831d13e082b167cfce
Reviewed-on: https://gerrit.libreoffice.org/52074
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I2028bb9664caf9b9c09d22cc766f88094c92b95f
Reviewed-on: https://gerrit.libreoffice.org/42940
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
|
|
Change-Id: I8e36ad989ec54117f85105c24bc1c1442e0a493b
Reviewed-on: https://gerrit.libreoffice.org/15454
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
|
|
Change-Id: Id5f22ac0f9fcfd7ab064111aec9abb00707d3e67
|
|
The 'suffix' GNU Make function returns the file name suffix including
the period. The test comparing to the string 'zip' will thus never
match, and gb_UnpackedTarget_STRIP_COMPONENTS_ZIP_DEFAULT will not be
used, but gb_UnpackedTarget_STRIP_COMPONENTS_TAR_DEFAULT. But as most
of the Zip archives we unpack do have a top-level with a single
directory anyway, that we want to "strip", that works out
fine. Apparently those that don't have a such directory level pass a 0
as second argument to gb_UnpackedTarget_STRIP_COMPONENTS_ZIP_DEFAULT
which has the effect of avoiding the "stripping".
Not sure what to actually do here, so I just commented the
situation... Should the code be fixed to do what it thinks it is
doing, but then to keep things working as before, should
gb_UnpackedTarget_STRIP_COMPONENTS_ZIP_DEFAULT be changed to 1?
Change-Id: I6436865dafe47e21e1365a602889cedab3c09784
|
|
Change-Id: I0a649548088428bd1a1fcedab76325fffa6b72a0
|
|
Change-Id: I78f56bb28d4b9b6c0696f83f3e06d836fd3427cd
|
|
Change-Id: I1101b87d3f34169f985924f8b867511e68ed5b66
|
|
Change-Id: Ib9c92c059eaec367c809949550d9991e8bd10d93
|
|
- this renames the 'almost' module target to non-l10n
- and adds a l10n target which is intended to only build l10n parts of
the product
- packagers should then be able to build l10n and non-l10n parts of the
product independently, thus:
- enable quicker rebuilds
- distribution of load
- updates to l10n without a full rebuild
- security fixes to binaries without rebuilding all l10n
- the new targets are called build-l10n-only and build-non-l10n-only
- note this is not intended to move a concept of split packages
upstream -- while this exsists in distros, the number of test
scenarios for this would explode upstream
Change-Id: Ib8ccc9bc52718d9b0ebbfee76ad93dc29c260863
Conflicts:
filter/Module_filter.mk
|
|
- WORKDIR path is just workdir
- INSTDIR path is just instdir
- WORKDIR_FOR_BUILD is workdir_for_build
- INSTDIR_FOR_BUILD is instdir_for_build
- replace other usage of INPATH by combination of OS and CPUNAME
Change-Id: Ie398387ebd82a968ec2605f2103c55b43a231482
Reviewed-on: https://gerrit.libreoffice.org/6601
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
|
|
mv only moves non-hidden files out of UNZIP_DIR, hence removal of
UNZIP_DIR can fail if there are hidden files remaining. This assumes
that hidden files aren't actually needed for our purposes.
This is a problem e.g. for libatomic_ops which contains a .gitignore
in it's top directory, causing the removal of UNZIP_DIR to fail.
Change-Id: Ia4a621b90bc4cc5fc15dd2a3ecc209734abc6269
Reviewed-on: https://gerrit.libreoffice.org/5808
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
|
|
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>
|
|
|
|
Change-Id: I97d30afe3a24aab1123352da05b066095e5c86bb
|
|
Change-Id: Id4639f1b0eefe5d433c84f48b7a1093fa17a3ba4
|
|
This function is for running arbitrary command just after unpacking. It
turns out that gb_UnpackedTarball_set_post_action is not enough :-(
Change-Id: Ibad9d7fbcdd2b95a16cc838ad8773eef5c6da019
|
|
This can apparently happen when interrupting a build; reproducible with
"touch workdir/*/UnpackedTarget/*openssl* && make openssl".
The -f parameter would apparently silently ignore some mal-formed
patches but at least it rejects potentially reversed ones,
which causes the "error handler" in gb_UnpackedTarball__command
to touch the "prepare" target so the next make is successful.
Change-Id: I7bbd7d9385d990a69214a3a2d9bb20b5a7173748
|
|
$(lastword $(MAKEFILE_LIST)) is not what is expected if the makefile
includes other makefile as the first step (as some do). See
UnpackedTarball.mk, where I already tried to workaround the problem.
Change-Id: Ib713a698f52ba16f46fbbc4c50b43edd69c9a472
|
|
... before somebody gets the bad idea of actually using it again.
No longer used in boost since a53586f4efe26b8875107d04001f4ecec760c343.
Change-Id: I41edb22ae8e7e36f40b24eb4479da874fb9a6c29
|
|
An user-friendly target sometimes needs to depend on a different target
than gb_Classname_get_target to really build everything (esp. to deliver
the built product). The rule of thumb is: use the same target that is
used for gb_Module_register_targets.
Change-Id: I874751871b4569b2a68766cc3f3b5c7645347af0
|
|
Change-Id: I002470c2888d6dec876af18c2c016cc789eb399e
|
|
Change-Id: Id7d8bc05b1393cc2bae4a531c8a47f62df24b1d6
Reviewed-on: https://gerrit.libreoffice.org/1488
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
|
|
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>
|
|
xmlsec1-mingw32.patch patches keywrapers.c
|
|
Change-Id: I5536d92c381a0df425a7d70387f1ebc457e68186
|
|
Change-Id: I02b1935a50ad1befe9630be8bd07792370d83bfe
|
|
Conflicts:
config_host.mk.in
Change-Id: I98ca1bb2af19d99a7a908991cf27a148ee84c543
|
|
Change-Id: If84003c6a95cee0fd6e4e985ec0655f7074b0851
|
|
also add the support for the convention that a patch filename
encode the -p value if it end with .[0-9]
for instance foo.patch.2 indicate a -p2 patch
usage:
generate a 'reference' copy of the expanded and patched file structure
$> make clucene.clean
$> patches=t make clucene
go to the module
$> cd clucene
edit files in $WORKDIR/UnpackedTarball/clucene
force a rebuild of things that depend on that UnpackedTarball
$> make clucene.rebuild
create a -p1 patch named clucene.new.patch.1 in the module's directory
$> make clucene.genpatch
you can then rename it, place it where appropriate in the module
hierarchy, update the UnpackedTarball_lucene.mk to apply it.
rinse and repeat from the top (yes the make lucene.clean is needed
to regenerate a 'reference' expanded and patched tarball)
Change-Id: I419c54a5981cffa385521596ba5016d2ca7ef52a
Reviewed-on: https://gerrit.libreoffice.org/712
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
|
|
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: I82da01827472c1fbcbfd821713ba7152421f18ff
|
|
Change-Id: I0164552ea9f2024eb5c44ad3b2b6181f6a9e3a1e
|
|
Change-Id: I74cc4752ac4abfd83f9eafa01ae4eb1813bb2afa
|
|
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: I033e2ab491498ba6b393232bff702db0a52e9a92
|
|
... perl script to convert line ends.
Change-Id: Ia2f6f38b39876946ba4471f99a7622241ae72017
|
|
Change-Id: Iaf6908ede1d06a7b36eca8f16f44716181428ce8
|
|
Change-Id: I8bf119a4ab3fc7c2febfa80176358f668003b7d1
|
|
Change-Id: Iabf62eb089530dff97c0a920b2be9c239b02d5b8
|
|
Change-Id: I48d86df772655229a08653e6c8f263338f69fbfb
|
|
Change-Id: I1ae354e3bf85c29679919f6382e14d3e4232d798
|