The interaction of environment variables and make variables is fun.
For some reason, the
workdir/.../UnpackedTarball/nss/mozilla/nsprpub/configure script is
run twice: Once directly from nss/ExternalProject_nss.mk, once from
the sub-make run from nss/ExternalProject_nss.mk. In the first case,
the AR and RANLIB exported by the gbuild make process propagate just
fine to the configure script. In the latter case, not. So add AR and
RANLIB assignments on the sub-make command line (to override values
set in some of the nss makefiles), *and* make sure the sub-make
exports AR and RANLIB.
Change-Id: Ibd55bc8a7e001106e12b2207500e74c7bd01c73a
nss uses hard-coded @executable_path (which is wrong, consider e.g. the case of
the URE uno executable), so patch it to use @_..._OOO instead (and no need to
set --prefix), and pass the resulting libs through macosx-change-install-names
(which requires the generated libs to be writable).
Change-Id: I0f04533f0f0581ee7b9dfd8929b8629c0842cc1b
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
"Octal literals are no longer of the form 0720; use 0o720 instead."
See http://docs.python.org/3.0/whatsnew/3.0.html
Seems ok with Python < 3
Change-Id: I588a9dcc4f4b447d5cb88eb6bb03ab2d598dc9f0
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>
It's fairly pointles to play with Unix rwxrwxrwx modes on Windows. One
never knows for sure how some emulation layer (Python's in this case)
guesstimates and mishandles the conversion to Windows ACLs. Not doing
them on Windows unbrokw the nss build. For me at least.
Change-Id: Id3a2f1755cd6f64bd681a3b4cb7f3c7abd3aa5b7
nss is not in tail_build because of moz, so expat, external, openssl and
python3 must go also out.
Change-Id: I52a3b02ff477ae52abc298d96770755ebc392d57
This removes the need for using NSS Build Tools on windows.
It also removes the nees to build nss for the build system while cross
compiling.
Change-Id: I13c9fdb575223f2940d3e4eda00e77ba9158f2b7
Reviewed-on: https://gerrit.libreoffice.org/1534
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Tor Lillqvist <tml@iki.fi>
Not sure what's wrong exactly, but on one tinderbox cl fails because
of "unknown" argument (unix path to the source file). Work it around
by explicitly converting the path to windows path.
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
In an MSVC build, not exporting BUILD_OPT to the Mozilla build
machinery causes the produced DLLs to use the debug CRT. The exact
mechanism is a bit of a mystery, and I didn't feel like spending too
much time trying to understand it.
Using the debug CRT is confusing and wrong. Nothing in LO otherwise
uses it. It also makes testing a build much harder for me at least, as
I do that in a fairly pristine virtual machine with no MSVC debugging
runtime available. (The normal CRT is bundled in the LO installer.)
Change-Id: I27f774d92a3986d40162c870202bcdddd94aa7c6
Rename the --enable-cl-x64 switch to --enable-64-bit and make its
meaning more generic. Drop the CL_X64 config variable, introduce the
more generic BITNESS_OVERRIDE instead.
Does not build yet.
Change-Id: Iac66afe31dceaf40c8262fec2e5aef6a751ba3d2
