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 6afe0e5804.
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 f4ae375c00.
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
