Commit Graph

12 Commits

Author SHA1 Message Date
ed26c01be1 quiet external module build log unless failure
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>
2013-02-22 08:25:56 +00:00
0f6f38b5d7 Fix 64-bit OS X build: don't try any universalness 2013-01-02 20:55:12 +02:00
9ddba66440 convert openssl to gbuild and add to tail_build
Change-Id: I52c62a91e317f072237cf25ed54f3cc6456d82b3
Reviewed-on: https://gerrit.libreoffice.org/1495
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
2012-12-31 20:13:20 +00:00
4ea11e31e9 /p:VisualStudioVersion=11.0 here, too
Change-Id: Ifa463327e9f33696012b3add0640b12f6d585178
2012-12-18 16:53:42 +02:00
773df2cb86 Nah, wrong to use /p:PlatformToolset=Windows7.1SDK
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
2012-11-30 10:58:47 +02:00
1ea411fb15 We need to tell the MSVS 2010 build to use Windows7.1SDK
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
2012-11-30 01:22:22 +02:00
49313b0626 Make python3 work with custom VALGRIND_CFLAGS
Change-Id: Ia4b08a1b20bf46af4d06c0478ed8e795ee543703
2012-11-27 15:35:02 +01:00
bee01c825b python3: build LibreOfficePython.framework on MacOS X
Change-Id: I0815aa0f5b50166f626f721be56969c0afd655a8
2012-11-26 23:14:34 +01:00
1f8d5eed2a python3: fix typos in makefile
Change-Id: I61ea54ff5a5771ad2dee1b3514c97fbdd9f241b9
2012-11-19 13:37:28 +01:00
f36b2f4320 Using --with-system-expat does seem to work also for a "bundled" one
Change-Id: Iff8904ac0c856dd3175b429b4919a04a57c1b6ad
2012-11-19 12:17:51 +02:00
d3e0fe8213 Make building python3 with current MacOSX tools proceed a bit further
I used the latest Xcode and the 10.7 SDK. Configures, and compiles
(for a while? all that is expected?), but then fails with cp:
.../workdir/unxmacxi.pro/UnpackedTarball/python3/python is a directory
(not copied). That is from ExternalPackage_python3.mk.

No idea how well, if at all, it configures and builds using the Xcode
2 or 3 compiler and 10.4 or 10.5 SDK.

Change-Id: I3ae838263a4db1b67e7c835e567540fac60b98bf
2012-11-17 14:37:02 +02:00
8a6c5b2fcb python3: add module for internal Python 3 build (not active yet)
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
2012-11-17 00:45:13 +01:00