On --disable-openssl, let's avoid linking the
bundled postgresql to OpenSSL by not passing down
--with-openssl to its configure script.
Also, configure stage will fail if krb5 or gssapi
are enabled as they need OpenSSL and, in any
case, --with-krb5 and --with-gssapi will not be
passed down to postgresql configure script.
Change-Id: Iaf7e944d1d8f6a018e949ece56f6d3881f1e8c46
Reviewed-on: https://gerrit.libreoffice.org/3333
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
When running module-deps.pl postgresql gets built just so that
libpq-flags.mk can be included. Since we already have all the necessary
libraries, add them explicitly and avoid this.
Change-Id: Icd94fc215ecb26c95f9ae3c14625bf819bf3c5c3
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>
Rationale:
- it is advised to use max-jobs and num-cpus with the same value in wiki
- max-jobs was used only for lcms2 and few gbuild
modules outside of tail_build anyway.
Also fixes:
- really use CHECK_PARALLELISM when meant to
- EXTMAXPROCESS is not defined in gbuild;
use parent's jobservers in sub-make where possible
Change-Id: I501de732d223ce0c935081bd1d73da611d16ee88
Reviewed-on: https://gerrit.libreoffice.org/930
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
The postgresql static library on Windows is named libpqd.lib in
debug and libpq.lib when compiled in release. We prefer to not
touch the external postgresql, so we make the proper changes in
the connectivity module.
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
...so that it does not miss any required libs due to picking up others first
that indirectly provide the required symbols; that would break our
libpq-flags.mk which should contain all the required libs when linking in the
static libpq.a.
Just a start, I suspect the configure script here will fail anyway
when cross-compiling to Windows at least. And we surely won't even
bother trying cross-compile this to non-desktop OSes.
1) When building internal pgsql even on Windows, we use Mozilla LDAP if it is built
2) Regenerate the generated fils with autoconf-2.63 that is used by upstream
