On --disable-openssl, the bundled neon library
will link against GNUTLS + gcrypt instead of
OpenSSL.
Change-Id: I5b3f09cd1003aefde0478aaab026536c962212c4
Reviewed-on: https://gerrit.libreoffice.org/3330
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
Most of the components included in LibreOffice
already support alternative TLS libraries (e.g.
NSS, GnuTLS).
Change-Id: If00c348046fdbc88156f3d89c25e874e7e9bd04c
Reviewed-on: https://gerrit.libreoffice.org/3328
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
There is no configure switch for this, URELIBS must be set.
This commit changes strategy to link also libraries being merged.
We need them for build tools like idlc, cppumaker, .., so the tools can
link against them now. This avoids circular dependencies.
Change-Id: Ic49e18ecbeaff84d4f5a7fafe8b1fbf45ed18c9b
one variable to find them,
one variable to deliver them all and into filelist put them,
in $INSTDIR where the installer searches.
Change-Id: I989f578f0ed6f9ef9167522249b36d95c15bfd1b
I get the below warning for every single jar file without this patch.
warning: [options] bootstrap class path not set in conjunction with
-source 1.5
1 warning
Change-Id: I71c01aeea993640f1ec86fe1d8a977656861358d
This is preparatory work for creating installation directly by gbuild.
Change-Id: I1b11db37c76ff781731845650169f39cb78fe820
Reviewed-on: https://gerrit.libreoffice.org/3189
Reviewed-by: Fridrich Strba <fridrich@documentfoundation.org>
Tested-by: Fridrich Strba <fridrich@documentfoundation.org>
Since we no longer support the old Apple SDK using gcc-4.0.1, we can
remove the cruft to work around its problems. Woohoo.
Change-Id: Idf275e76449443f1f0314e75dab993f213a77eb7
This reverts commit 151abb8b2b.
Unfortunately has the side effect that it will prevent GCC from
generating makefile dependencies for headers from bundled external
libraries, which breaks incremental builds horribly.
(Retain the uses in configure for real system headers).
Conflicts:
RepositoryExternal.mk
configure.ac
Change-Id: I149db1d402fa18bdc470f90dee846cfb5158237e
...which is no longer used. Also, use the detected BASH value in Makefile.in
instead of re-detecting there. (Though setting SHELL in Makefile.in is likely
bogus anyway, cf. "this is overridden by solenv/gbuild/gubild.mk [...] i don't
know what needs the 'SHELL=bash' in top-level makefile",
<http://lists.freedesktop.org/archives/libreoffice/2013-March/048552.html> "Re:
need help with shell / configure.")
Change-Id: I09c8b5eb9fb1244321d1fb998bb78e458e8ebf37
When running module-deps.pl postgresql gets built just so that
libpq-flags.mk can be included. Since we already have all the necessary
libraries, add them explicitly and avoid this.
Change-Id: Icd94fc215ecb26c95f9ae3c14625bf819bf3c5c3
This should avoid gcc warnings in external code we don't care about,
so there'll be no need to fix them for WaE.
Change-Id: I629dc2672c075908294609249183f27ad2984325
Also simplifies configure, hopefully without any mistake;)
Change-Id: I5c6c53fbee06cd1ecccf878a5c080274bfd950c1
Reviewed-on: https://gerrit.libreoffice.org/2563
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
I think it should die completely but openbsd and solaris still use it.
Probably just setting LDFLAGS should be enough for them ?
Also SOLARINC_FOR_BUILD and SOLARLIB_FOR_BUILD are not used anywhere.
Change-Id: I1c11981f859876af8b90e8ba60fce2820b354022
Hopefully all stays the same except for vcl/unx/gtk/a11y/atkutil.cxx.
Change-Id: I49108007ee6d045f045de86c8654efc7ca5fd3d0
Reviewed-on: https://gerrit.libreoffice.org/2491
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Ostrovsky <David.Ostrovsky@gmx.de>
Tested-by: David Ostrovsky <David.Ostrovsky@gmx.de>
This is writing history: LibreOffice builds in ONE non-recursive make process
with full dependencies. We will now be able to really move forward without the
old build system. A big 'Thank you!' goes out to everyone contributing to
solenv/gbuild, especially:
- David Tardon
- Norbert Thiebaud
- Tor Lillqvist
- Michael Stahl
- Matúš Kukan
- Stephan Bergmann
- Luboš Luňák
- Caolán McNamara
- Mathias Bauer
- Jan Holesovsky
- Peter Foley
- Andras Timar
- Hans-Joachim Lankenau
and all the heroes migrating all the modules of LibreOffice to gbuild.
By explicit request this commit has to be completed with this quote:
I say we take off and nuke the entire site from orbit.
It's the only way to be sure.
Hold on a second.
This installation has a substantial dollar value attached to it.
They can bill me.
Change-Id: I72fa17cfb24fae00ca78cfe0eb5782c1788d2dcc
Reviewed-on: https://gerrit.libreoffice.org/2445
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Niko Rönkkö <ronkko@iki.fi>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
It has served well but it's useless nowadays.
build.pl is going to die anyway.
Change-Id: I7769528af7987e43fee8707ce5b4e2214d43c5b4
Reviewed-on: https://gerrit.libreoffice.org/2174
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
--with-referenced-git works with submodules, --with-linked-git does not.
And I don't see a way to fix it, either.
Change-Id: Ib6cdb065a022665cd62e9fdc7fc37a9e916e50ad
Reviewed-on: https://gerrit.libreoffice.org/2165
Reviewed-by: Matúš Kukan <matus.kukan@gmail.com>
Reviewed-by: Björn Michaelsen <bjoern.michaelsen@canonical.com>
Reviewed-by: Miklos Vajna <vmiklos@suse.cz>
Tested-by: Miklos Vajna <vmiklos@suse.cz>
This is similar to --with-linked-git, but:
1) It uses git submodule update --reference, so it works with submodules.
2) The created repo is a true git repo, except that its object database
reuses the referenced repo's objects, so it's a real speedup when e.g.
translations are enabled.
I intentionally didn't just fixed --with-linked-git, to make it clear
this is more like git clone --reference, not git-new-workdir.
Change-Id: I7c9584bce3670fd1e175b90aded2435cfe78056d
Not yet implemented in the code, but my idea is that any functionality
that modifies the system-wide installation will go away in this case.
Automatically set if --disable-externsions, or if building a sandboxed
LO for OS X.
Should probably be set automatically also when just building a signed
(but not necesssarily sandboxed) LO for OS X? Surely installing a
system-wide extension should count as tampering with the
app. Especially if we can make also extension (scripts) be signed (by
locating them in the Resources folder?)
Change-Id: Id654bfaa6331535a66eae1bc6531a756085a3f06
