Age | Commit message (Collapse) | Author |
|
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
|
|
Change-Id: Ic6645e9943b2445ebb37bb99114f777527c69af9
|