Had been totaly broken by the recent changes. (Which is fine, it is
just an experimental hack anyway, I am not sure whether it will ever
be used in anger. Just a pet peeve of mine, I dislike seeing
libraries, configuration files, resources etc mixed together in one
"program" folder, especially on OS X, where the convention is to have
app-specific dylibs and frameworks in "Frameworks", and resource files
in "Resources". But this is not any requirement as such; there are
apps in the Mac App Store that blatantly "break" this convention.)
Basically, replace uses of gb_PROGRAMDIRNAME and
gb_Package_PROGRAMDIRNAME with more specific LIBO_FOO_FOLDER, which
for normal builds all expand to the same "program" anyway.
Change-Id: I16c2b3351caa00e251e229aafbccb8346042d3c1
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
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
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
- 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>
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
The module builds here on Fedora 17 and with MSVC2008.
MacOS X is unfinished and probably breaks, which is why the module
is disabled now.
These patches from module python were dropped:
Integrated upstream:
- Python.mipsel-py4305.patch
- Python-2.6.1-py4768.patch
- Python-2.6.1-py2422.patch (modified, use --with-valgrind)
- Python-2.6.1-urllib.patch
- Python-2.6.1-py8067.patch
Obsolete:
- Python-2.6.1-svn-1.7.patch (migrated to non-toy HG now)
- Python-parallel-make.patch
- Python-2.6.1-nohardlink.patch (no idea why that would be needed,
NFS should support hard links)
- Python-2.6.1-sysbase.patch (Solaris 11 setsolar specific patch)
- Python-2.6.1-cross.berkeleydb.patch (berekeleydb removal)
- Python-2.6.2-bdb48.patch
- Python-2.6.1-vc10.patch (upstream supports vc10)
An attempt to cross compile with mingw that proved unsucessful according
to dtardon; there is upstream work on this topic that is possibly
already in 3.3: http://bugs.python.org/issue8067
- Python-2.6.2-cross.patch
- Python-2.6.2-cross.fix-configure.patch
Change-Id: Iba9a3cab955983e173e12110f93a6f381d86f9ce
