Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
Note: do NOT put file paths to static libraries into FOO_LIBS variables
that are passed to bundled externals that are built with --enable-static:
on Mac OS X this will result in .a archives that contain other .a
archives as entries, and trying to link those results in errors like:
ld: warning: ignoring file .../libodfgen-0.0.a, file was built for
archive which is not the architecture being linked (i386)
Change-Id: If2c5a458058e4da76f80b3643e55b489d1edee24
/usr/bin/install -s will invoke "xcrun strip", and there are a few
hardocded install_name_tool left.
Change-Id: I839af379320b4886c45a12c9a1d4fa88d2ef0059
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
Apparently the native modules (.pyd) are expected directly in lib, not
in lib/lib-dynload like the .so's on linux.
Change-Id: Ic3181f189d9db51cb57630c4c1ea8741bbf879ec
program is only a symlink to it there, created by the installer.
(Hmm, would it be possible to have MacOS symlink to program instead? It
would simplify things :-)
Change-Id: If21df47da5ac7c77358656f40d9caaaa62a7e87f
Internal zlib is not really supported anyway on any platform that uses
setup.py.
This reverts commit 6afe0e5804f2a23f9fc9842d372fff77fd1023f1.
Change-Id: Icf94a85c4baf00df54ee5dcca5fe3ca4a63a54a8
- python3: deliver files to INSTDIR, with same layout as instset
and do not deliver .lib files
- pyuno: remove obsolete python.bin targets
- pyuno: remove usage of CustomTarget_zip for WNT and non-Mac UNX
platforms (sadly it is apparently still needed for "system" python on
MinGW)
- scp2: use the python3 filelist
There is still a problem here because the installer does not currently
allow to preserve the executable bit on files in a filelist
- RepositoryExternal: run python executable from INSTDIR
and link against libraries in UnpackedTarball dir
Change-Id: I931ca0a8be6ff40051b1ca50da1f0770e6057832
Reviewed-on: https://gerrit.libreoffice.org/3525
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
These were apparently accidentally disabled on all non-WNT platforms.
Set the OPT variable from the outside on the platform that needs it.
(regression from ab41efc81ec26fcbd4cdeb9c36fbe8cc274523f)
Change-Id: Ifbf7ec8e0f863cb6368758571496c8b615e3e814
Add patches and/or tweaks to the following modules:
curl, cppunit, icu, lcms2, libxml2, libxslt, libxmlsec,
lpsolve, nss, openssl, python3
lcms2 has an inconsistency where the .lib and the .dll don't agree on
the .dll name.
openssl gets a honorable mention because apparently it's undocumented
custom build system can build with /MDd if one picks the right
configuration but i couldn't figure out how to do that in an hour of
trying, and just patched the release config instead.
Change-Id: I7854a0fc85247e398d561b4f513d09fe2d1ebb3c
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>
That python bug cause problems when libreoffice is on a read-only
media... which is very common for Mac as the dmg used to package
the produce is seens as a read only volume.
This patch the bug 15833 for MacOSX only since that is the platform that
is most likely to be impacted, and because of bug 15431 that make
patching on Windows more complex/dangerous.
Change-Id: Ie7406c1c75748d38c871b3b544560caa62e9d838
Reviewed-on: https://gerrit.libreoffice.org/1934
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Failures to build some python modules are actually not fatal, I just got
confused because the whole python build runs in parallel to the normal make.
This reverts commit f4ae375c00deb2297074c59b62db87de080bf591.
Apparently all recent systems use ncursesw, for which there is
-I/usr/include/ncursesw, but SLED11 uses ncurses lib, and there's no -I for that.
Change-Id: I61ec795aae45e1074075351eca62299784d08b09
It must be my local installation of VS2010 that is somehow screwed up
when building here it doesn't find <windows.h>. I need to fix that
instead.
Change-Id: I37a5f8b41f193b108f33464a6a127c0a5969d232
At least for me it wouldn't build otherwise. But yeah, what it
somebody uses MSVS 2010 with another SDK? It seems that the solution
only offers the SDK 7.1 as an alternative?
The default was v100, whatever that measn. Could it be that my MSVS
2010 installation is borked? Or that I did not have to install a
bundled SDK with it, because I already had a separate 7.1 SDK?
Also simplify a bit, no need to $(filter) on VCVER inside ifeqs that
already check the very same VCVER.
Change-Id: Ifef98c9466fc24db27d9e38c6878c77adfb4ed75
Otherwise it would try to build the ssl.vcxproj which we don't want
(because we want to use the openSSL already built from solver), and
which fails anyway because for some reason it wants to run
python_d.exe.
Change-Id: I7471bc26ae96be84b976ba35bb959d75678df980
