on Windows and macOS autogen.sh could misdetect the build directory as
being different from the source directory if the filesystem is
case-preserving but not case-sensitive. e.g.
cd ~/BuildDir ; ~/builddir/autogen.sh
It is the same directory, but treated as a different one and thus
autogen would create the module/Makefile files and also a link to the
include directory. That however then ends up being a include/include
link and that then fails the skia build.
So use the same method to get both paths to avoid the problem.
Change from cwd() to getcwd() since despite the documentation saying it
would be the same, getcwd is actually returning the actual name as
stored in the filesystem. Also use the module's chdir so that the PWD
environment variable doesn't need to be set manually.
Change-Id: I705dc584a91be9f63052bd1f72d4a0c4ba73f3ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/187536
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Regina Henschel <rb.henschel@t-online.de>
Tested-by: Jenkins
windows build doesn't make use of system libraries, so we only need to
make autoconf/configure happy (allow it to use PKG_CHECK_MODULES macro)
but for that adding the m4/mac path is enough (there's nothing mac
specific, just the pkg-config macros have been added for mac initially)
Change-Id: Ia5db12833c26d89b7e0dbd7009562836885d8055
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177562
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
while regular "make module" commands don't make use of those Makefiles
(and instead cd to $srcdir/module before running make there), some
users run "make -C module -rs SUBTARGET" in which case they would be
read.
autogen.sh did create wsl-style paths that the windows side can't
resolve. So make sure to convert them to windows-style paths when
running inside wsl with ming64 in path (=autogen is running inside wsl,
but was started from windows-side, to distinguish from the case where
autogen is started from within wsl to create a linux build)
Change-Id: I0b3d9fda9bc22ebd27edaaad75233a84b33e61c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174900
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
autogen.sh is a Perl script. When running Perl on WSL, weirdly named
environment variables like the "ProgramFiles(x86)" one don't seem to
get imported to a shell child process of the Perl process. So export
it as PROGRAMFILESX86 instead. configure.ac will look for that on WSL.
(Changes to configure.ac will be coming in small careful steps.)
Change-Id: I572c3b1e2f2fab3629d1856d33fcf0dda51217d6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103921
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
autogen.sh seems to be used as a preprocessor for configure script,
so it has only a few options itself. However, "--clean" option,
which is even documented in script's help message, now touches only
two items in repository (on Windows): autom4te.cache folder,
which is refreshed during autogen.sh run anyway, and install-sh
script, which is NOT regenerated afterwards. So using --clean
actually breaks configuration setup.
Please check if anyone still uses --clean for its original purpose
and remove this feature or automate install-sh regeneration.
Change-Id: Ic3991ea4e53cea5ad07696f9b75acf9176eb7ce1
Reviewed-on: https://gerrit.libreoffice.org/85247
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
partially reverts 182f5a0f34 in the sense
that configure still insists on autoconf 2.68, but in a way that allows
to specify an already installed copy (that the libnumbertext build
already picked up successfully)
While there is autoconf268 package, it gets installed as autoconf268, but
aclocal doesn't provide a way to use something else than "autoconf"
In the spirit of "keeping it simple", no conditional check is done
whether libnumbertext is actually enabled or not.
Change-Id: Ice05a70ef56a4ed3428c74d15d6aeeaa54f71c0b
Reviewed-on: https://gerrit.libreoffice.org/67159
Reviewed-by: Michael Stahl <Michael.Stahl@cib.de>
Tested-by: Jenkins
Enabling it in the relevant distro-configs/Jenkins/* file is more intuitive than
enabling it in autogen.sh (and avoids issues like
d057e61cb5 "Restrict Developer Toolset to
Config=linux_gcc_release_64"), and will also be used for other Jenkins jobs like
<https://gerrit.libreoffice.org/#/c/63982/> "Enabling Developer Toolset 7 for
Jenkins' lo_tb_master_linux_dbg".
Change-Id: If633044a90c35a12a73d60335839af0a106aa20f
Reviewed-on: https://gerrit.libreoffice.org/63989
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
The Jenkins "Gerrit Linux clang/dbgutil" builds started to fail in odd ways,
presumably because of having the Developer Toolset in the PATH now when building
compilerplugins. So change compilerplugins/clang/pluginhandler.hxx slightly to
force rebuild.
Change-Id: I97b8f89dc2e20c85f130284ca5326a5c96c2a1ba
Reviewed-on: https://gerrit.libreoffice.org/63962
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...as discussed at
<https://lists.freedesktop.org/archives/libreoffice/2018-November/081423.html>
"Re: Compiler baselines".
It doesn't look exactly right to enable the Developer Toolset from autogen.sh.
But the alternative would be to "hide" that in
<https://ci.libreoffice.org/job/gerrit_linux_gcc_release/configure>, which would
probably not be helpful when developers try to track down why a certain Jenkins
build behaves the way it does. So pragmatically stick it in autogen.sh. (Also,
it puts Developer Toolset on the PATH whenever it is found on a system using
LODE_HOME, not just for the specific Config=linux_gcc_release_64 case. Lets see
how that works out in practice.)
However, it turns out that the Developer Toolset 7's GCC 7.3.1 with
--enable-werror (that is implicitly enabled for LODE-driven builds in
configure.ac) and (implicit) --enable-optimized produces many false warnings
(i.e., errors), see below for a sample. (Actually, my experience is that
contemporary GCC hardly ever work with -Werror in optimized builds, due to
analysis being done on already optimized code; it surprised me to find out that
the Jnekins linux_gcc_release_64 builds were apparently successfully done with
--enable-werror with GCC 4.8.5.) So explicitly --disable-werror for these
builds. (Which means that <https://gerrit.libreoffice.org/plugins/gitiles/lode/
+/b82e0a9d26ef4c81046c053ff831dccfc84c56be%5E!> "For linux_gcc_release_64, don't
let ccache strip comments" could probably be reverted again if it has negative
impact on Jenkins' performance.)
Some of the false warnings encountered:
> [CXX] jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
> In file included from /opt/rh/devtoolset-7/root/usr/include/c++/7/vector:69:0,
> from /home/tdf/sberg/core/jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx:39:
> /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc: In function ‘javaPluginError jfw_plugin_startJavaVirtualMachine(const JavaInfo*, const JavaVMOption*, sal_Int32, JavaVM**, JNIEnv**)’:
> /opt/rh/devtoolset-7/root/usr/include/c++/7/bits/vector.tcc:407:15: error: variable ‘__new_finish’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered]
> pointer __new_finish(__new_start);
> ^~~~~~~~~~~~
> cc1plus: all warnings being treated as errors
> [CXX] libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx: In function ‘gboolean gtv_calc_header_bar_draw(GtkWidget*, cairo_t*)’:
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:117: error: ‘aRectangle._cairo_rectangle_int::height’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
> ~~~~~~~~~~~~~~~~~~^~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::height’ was declared here
> GdkRectangle aRectangle;
> ^~~~~~~~~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:59: error: ‘aRectangle._cairo_rectangle_int::width’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
> ~~~~~~~~~~~~~~~~~^~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::width’ was declared here
> GdkRectangle aRectangle;
> ^~~~~~~~~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:97: error: ‘aRectangle._cairo_rectangle_int::y’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
> ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::y’ was declared here
> GdkRectangle aRectangle;
> ^~~~~~~~~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:89:40: error: ‘aRectangle._cairo_rectangle_int::x’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
> cairo_move_to(pCairo, rRectangle.x + rRectangle.width / 2 - extents.width / 2, rRectangle.y + rRectangle.height / 2 + extents.height / 2);
> ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
> /home/tdf/sberg/core/libreofficekit/qa/gtktiledviewer/gtv-calc-header-bar.cxx:102:22: note: ‘aRectangle._cairo_rectangle_int::x’ was declared here
> GdkRectangle aRectangle;
> ^~~~~~~~~~
> cc1plus: all warnings being treated as errors
> [CXX] svl/source/misc/lockfilecommon.cxx
> /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx: In static member function ‘static rtl::OUString svt::LockFileCommon::GetCurrentLocalTime()’:
> /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: error: ‘%02d’ directive writing between 2 and 5 bytes into a region of size between 1 and 9 [-Werror=format-overflow=]
> OUString LockFileCommon::GetCurrentLocalTime()
> ^~~~~~~~~~~~~~
> /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: note: directive argument in the range [0, 65535]
> /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:190:10: note: directive argument in the range [0, 65535]
> /home/tdf/sberg/core/svl/source/misc/lockfilecommon.cxx:204:24: note: ‘sprintf’ output between 17 and 31 bytes into a destination of size 20
> sprintf( pDateTime, "%02d.%02d.%4d %02d:%02d", aDateTime.Day, aDateTime.Month, aDateTime.Year, aDateTime.Hours, aDateTime.Minutes );
> ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> cc1plus: all warnings being treated as errors
Change-Id: I3a851b7591274a8cf8b4729ae036afeb8e82eedc
Reviewed-on: https://gerrit.libreoffice.org/63884
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
These were created as symlinks, which doesn't work with Win32 make as it
doesn't understand Cygwin symlinks.
Instead, create them as actual files.
Note: the reason why they work as symlinks at all is that the Makefile
uses $(realpath) and partial_build.mk does not, so they can
resolve relative paths from 2 different directories...
Change-Id: I4a9abffae82561111a9525fb35ed4b174cc8d96a
Reviewed-on: https://gerrit.libreoffice.org/56691
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <Thorsten.Behrens@CIB.de>
> Jan 18 15:18:25 <sberg> tml__, do you remember anything about
> e3a07b8a6c ? looks odd to add configure
> KEY=VALUE args to the environment
> Jan 18 15:18:27 <IZBot> core - Include environment variables already in
> autogen.sh's environment -
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=e3a07b8a6cc03b6d5063e4da5a474d8c91a84b0a
> Jan 18 15:22:54 <tml__> sberg: not really any recollection, sorry
> Jan 18 15:23:09 <tml__> sberg: are you sure this isn't what makes it possible
> to have CC=clang etc in autogen.input?
> Jan 18 15:24:07 <tml__> or maybe this is related to propagating stuff when
> make re-runs autogen.sh?
> Jan 18 15:24:28 <sberg> tml__, configure already takes care itself of its
> KEY=VALUE command line arguments
> Jan 18 15:24:36 <tml__> sad that I didn't write a better commit message
> Jan 18 15:24:55 <tml__> feel free to revert it, and see if anybody notices;)
> Jan 18 15:25:04 * cloph_away used it for CC/CXX and devtools repo
> Jan 18 15:26:11 <tml__> cloph_away: yes, but I think sberg says that should
> work anyway, even without that commit
The only reading from ENV after that code in autogen.sh (both today and at the
time of e3a07b8a6c) is the
if (defined $ENV{NOCONFIGURE}) {
print "Skipping configure process.";
check, which would now no longer work if you pass NOCONFIGURE= as an argument
to autogen.sh (in autogen.input or on the command line) instead of as an
environment variable.
Change-Id: If50639978190d219b063ff39f81e29d2054c0443
Reviewed-on: https://gerrit.libreoffice.org/48133
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which allows to align --enable/--disable switches on the part being en-/dis-
abled, as in
> --disable-assert-always-abort
> --enable-avahi
> --enable-breakpad
> --enable-build-unowinreg
> --disable-ccache
for better readability
Change-Id: I490402c74ea1ee535deee6ef79274b588b614820
Reviewed-on: https://gerrit.libreoffice.org/48130
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Welcome back autogen.lastrun. I just don't have the energy to convince
tinderbox maintainers to fix their scripts. Oh well.
This reverts commit 7496c83374.
This reverts commit 47bca2f064. I worry very much
when some --with-distro=foo due to a typo doesn't do what I'd expect, and the
non-fatal error message scrolled by so quickly nobody would notice.
Conflicts:
autogen.sh
Change-Id: I8e0938e28e5aa23b59c82bbd10db0018e32a44dd
Reviewed-on: https://gerrit.libreoffice.org/37701
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Jenkins <ci@libreoffice.org>
Without this, first lines (up to "Other arguments passed directly
to configure:" inclusive) go to STDERR, while the rest to STDOUT
Change-Id: I95327d1ebe7941e5eb89f941ff1f9dc59297946b
Reviewed-on: https://gerrit.libreoffice.org/31999
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
When using a LODE setup, LODE_HOME must be defined in the environment
but setting LODE_HOME/opt/bin in the PATH is optional
and really only necessary as a convinience to get the right
'make' in the PATH.
configure.ac has code do deal with the absence of LODE_HOME/opt/bin
in the PATH but autogen.sh did not hence was failing in this
case, not finding aclocal.
Change-Id: I7a4449504dc539bb055798a6e1aea5268c5fb046
Reviewed-on: https://gerrit.libreoffice.org/21003
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
When we add or deprecate configure --with / --enable options lots
of scripts can break. Instead just add --best-effort to your autogen.sh
command line to get warnings but not a failure in this case.
Change-Id: I73d6ba53ee179384c2e34bf6780d074b04f70c06
The change in partial_build.mk assumes all the Makefile's using it
are in builddir/<module>/ or builddir/external/<module> , these are
differentiated by checking for ../External_module.mk .
Change-Id: Iddc8fa2ec0842f181780f7491cf5a2244efd014a
This reverts commit 11e881a638, which assumed that
"all the Makefile's using it are in builddir/<module>/", which is not the case
for the external/ sub-modules.
The change in partial_build.mk assumes all the Makefile's using it
are in builddir/<module>/ , but that seems to be the case.
Change-Id: Iddc8fa2ec0842f181780f7491cf5a2244efd014a
Actually warn the user, if we ignore provided configuration files.
Also add an extended header to explain the expected behaviour.
Change-Id: I630d858c2d24aa0341d04359b45029c7faa54675
Reviewed-on: https://gerrit.libreoffice.org/8446
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
It might hurt a bit in the beginning if you have been careless with keeping
your autogen.input up-to-date, but I think this is a good idea.
Change-Id: I6b89c887c94755ac6ef50f63e0438ecec7157516
This is a partial revert of ca0c54d0fe .
Ignoring cmdline arguments if autogen.* exists is broken for several reasons:
- autogen.sh of every other package passes cmdline arguments to configure
- that's because if I was bothered to give them, I want them used
- there's no reason to prefer autogen.input now, given that autogen.input
cannot be overwritten by autogen.sh, unlike autogen.lastrun , so there's
no accidental loss of the switches
- running autogen.sh --foo followed by autogen.sh --bar actually runs
configure with --foo the second time too, because the first one creates
autogen.lastrun and the second one first complains about the cmdline
args, then complains about autogen.lastrun, and then uses it
Change-Id: I5868610935d0312915be74602b6435eea069f937
Reviewed-on: https://gerrit.libreoffice.org/3190
Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Tested-by: Luboš Luňák <l.lunak@suse.cz>
For backward compatibility, an autogen.lastrun file will still be used if it
exists and autogen.input does not exist. The recommended workflow is now to
keep the configuration parametets in autogen.input which is never written by
autogen.sh.
Most (?) developers used to treat autogen.lastrun as a valuable parameter file
to be edited manually anyway, and not as an ad-hoc backup copy of command-line
parameters last used. The name autogen.input better reflects this usage.
Change-Id: I7e3c747fa95e9f2f0bc44036419aaab8f4ad01e7
Reviewed-on: https://gerrit.libreoffice.org/3111
Reviewed-by: Michael Meeks <michael.meeks@suse.com>
Tested-by: Michael Meeks <michael.meeks@suse.com>
This patch allows to do
mkdir <build_dir>
cd <build_dir>
<src_root>/autogen.sh
make
Only the remaining dmake modules are poluting the <src_root>...
which will get eventually convererd to gmake...
Change-Id: Iefd64732fa12e096d554cff4eee6b777deb92338
Reviewed-on: https://gerrit.libreoffice.org/1273
Reviewed-by: Luboš Luňák <l.lunak@suse.cz>
Reviewed-by: Norbert Thiebaud <nthiebaud@gmail.com>
Tested-by: Norbert Thiebaud <nthiebaud@gmail.com>
Always try to read distro-configs/default.conf (if existing) before
any option parsing.
That way, downstreams (distros, etc) can just place there site config
into the tree without having to pass any additional options to autogen.sh,
and even automatic invocations will always have the right parameters.
Change-Id: Ic5bf68adc719476d374cf03e31e054b69c931b72
Reviewed-on: https://gerrit.libreoffice.org/1096
Reviewed-by: Andras Timar <atimar@suse.com>
Tested-by: Andras Timar <atimar@suse.com>
Christian Lohmaier