This wasn't working on Linux. Build was started no matter if unzip
was found or not. This lead to other errors and finally to a build
break. Hopefully this doesn't break other platforms.
This is port from the build repo. The main differences are:
+ splits package-ooo into several scripts (bin/distro-install-*)
+ renames many variables to avoid OOO prefix and to better fit
the variables produced by the current bootstrap configure.in
+ uses OOO_VENDOR from bootstrap/configure.in to add distro specific hacks;
the conditions have been updated only for "Novell, inc."
+ install most of the desktop integration from sysui using
sysui/desktop/share/create_tree.sh
+ do not install two extra templates:
$OOINSTBASE/basis$VERSION/share/template/en-US/forms/resume.ott
$OOINSTBASE/basis$VERSION/share/template/en-US/officorr/project-proposal.ott
should get merged with other templates
+ do not install pyunorc-update64;
it is needed only when you want to run 32-bit LO on 64-bit system;
is anyone using it?
+ do not call install-dictionaries:
+ do not call build-galleries:
is anyone using them?
+ do not install ootool and ooconfig
is anyone using them? are they still working?
Signed-off-by: Michael Meeks <michael.meeks@novell.com>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Bjoern Michaelsen <bjoern.michaelsen@gmail.com>
NATIVE indicates that the BUILD and HOST platforms are the same,
i.e. a "normal" not cross-compiling build.
DESKTOP indicates a "normal" desktop/server OS, like Linux, Windows,
BSD or Mac OS X. (Non-desktop ones would be "mobile" ones like iOS and
Android.)
(All traditional, and so far only actually working, builds of OOo/LO
is both NATIVE and DESKTOP. The non-NATIVE and non-DESKTOP cases
belong in the experimental cross-compilation work.)
All non-DESKTOP cases are also non-NATIVE, at least so far. In other
words, when building for a mobile OS we always cross-compile. Note
that the reverse is not true: We eventually would want to
cross-compile to Windows, rarer Linux architectures, and PowerPC Mac
OS X.
DESKTOP is used in build.lst files to indicate modules that it makes
no sense to build for mobile platforms. Nobody is going to run
LibreOffice SDK tools on a tablet.
NATIVE is used in build.lst files to indicate modules that produce
just build-time executables (which can't be run on the BUILD system
when cross-compiling), and which are not part of the SDK either.
(Sadly the use of BUILD_TYPE keywords in the build.lst files is a bit
tedious: you have to mark a module in the build.lst files of all its
"parents", modules that depend on it, not in that of the module
itself.)
It does make sense to build SDK tools in the other cross-compilation
cases. There is no reason why we wouldn't want to cross-compile also
the executables that go into the SDK when cross-compiling to Windows,
for instance.
It apparently doesn't have curl-config in
/Developer/SDKs/MacOSX10.4u.sdk/usr/bin, in fact no usr/bin in the
10.4 SDK at all. (The 10.4u SDK on Intel does have it.) Which is a bit
weird, I thought that SDK was supposed to be "universal" and the same
for both ppc and x86. But oh well, I will when necessary just set
CURLCONFIG in the environment when running configure then.
Hardcode use of the curl-config from the 10.4 SDK for MacOSX. Make use
of pkg-config to find libcurl when cross-compiling optional, if no
libcurl package found by pkg-config, use curl-config.
Like in my previous plan, when cross-compiling we run the same
configure script separately for a native build configuration on the
build platform, in a temporary subdirectory.
Now use a fixed name "CONF-FOR-BUILD" for that subdirectory, so that
it is easy to edit out that path component from those build
environment variables that contain it.
Pass more of the native build environment variables up to the main
configure and propagate those to the build environment suffixed with
_FOR_BUILD: INPATH, OUTPATH OUTDIR, PATH, SOLARINC, SOLARLIB,
WORKDIR. Whether these all will actually be needed remains to be seen,
the set can be reduced later.
The environment setting file (*Env.Set.sh) for the native build is
copied here to the top directory under the name Env.Build.sh, and the
environment variables set in it that contain pathnames are modified to
point directly to this top directory, not the temporary CONF-FOR-BUILD
subdirectory.
When doing a cross-compiling build, we first do a build of the
necessary build-time tools for the build platform. This is done in the
same source tree. As the directories where build results are stored
include the platform specification (OUTPATH or in some cases INPATH),
there should be no clashes.
Don't run the download script from ./bootstrap(.1). We are running it
from Makefile already anyway often enough. This could also do with
some clean-up; the ./g -f clone phase is a bit slow, I am not sure if
it really is necessary every time? Also, we should not overwrite
ooo.lst if its contents isn't changing.
Use INPATH_FOR_BUILD in SOLARBINDIR so that the self-built tools like
idlc that we run are for the build platform, not the host
platform.
Attempt to get rid of the makefile.rc and makefile.mk files. Surely it
should be enough with just Makefile(.in) (and then GNUmakefile.mk for
its own so far special gbuild purposes). Instead of invoking dmake to
do "clean" or "distclean" from Makefile(.in), we already just do the
same directly in Makefile(.in). This way we don't need to first build
dmake in order to be able to do a make clean, which will then finally
clean out dmake again;)
Ideally I would like to get rid of bootstrap(.1), too. It should be
possible to merge its tasks into configure(.in) or Makefile(.in) as
appropriate.
And actually, maybe also what set_soenv(.in) does could well be merged
into configure(.in)?
We want to be buildable on Mac OS X without pkg-config. For instance
Mono installs a symlink /usr/bin/pkg-config that just confuses this
goal if you happen to build LibreOffice on a machine with Mono
installed.
Use --with-system-librsvg also to direct whether to use the system
version of the libraries only used below librsvg (gdk-pixbuf, GLib,
libcroco, Pango, libgsf, I think).
There still is confusing overlap with older tests for librsvg, libpng
and libjpeg, which previously have ben relevant only on Unix
builds. This needs to be unified. Also, the new stuff that came with
the librsvg thing in m106 doesn't seem to use pkg-config, huh?
Reverse the sense of the messages for the new checks; instead of
saying "checking whether to build own version of libfoo... no", say
"checking whether to use system libfoo... yes". This matches the sense
of the corresponding SYSTEM_FOO variables, thus reducing confusion.
The configury in the bundled obsolete version of OpenSSL is just too
horrible to even bother patching up to work for cross-compiling to
iOS. There are several ways to build OpenSSL for iOS described on the
net, let's just use one of them.
Re-introduce the old --with-mingw option but now called
--with-mingw-cross-compiler. Its purpose is now specifically to give
the cross-compiler used when building the ODK, if Java is enabled, and
if building the unowinreg.dll. It has now nothing to do with
cross-compiling LibreOffice itself.
Correspondingly, the WITH_MINGW variable now has meaning only when
building LibreOffice for Windows: If using MinGW, whether natively on
Windows itself (which we as such don't intend to support, I hope), or
cross-compiling, it is set to "yes".
Automate and simplify the search for the MinGW cross-compiler when
intending to build unowinreg.dll on Unix.
Look for the usual tool-chain tools ar, nm, objdump, pkg-config,
ranlib, strip, and for Windows alto dlltool and windres using
AC_CHECK_TOOL so that the proper cross tools are found when
needed. Propagate to environment. As such these are not used except in
the MinGW mk files so far.
Other minor cleanups.
When looking for the db,h header, use Autoconf mechanisms instead of
manual checks in hardcoded directories. So yeah, this means that you
need to make sure the correct -I flag is passed if you have db
installed in a weird place where the compiler doesn't find it.
Use checks that require only compiling, not running code. Nice.
Don't AC_SUBST variables that are not used.
The Autoconf 2.59 on Mac OS X 10.4 for instance lacks
AC_CHECK_ALIGNOF.
This means we can't get rid of the typesconfig program in
sal/typesconfig until we can require a newer Autoconf.
Also correct the hardcoded alignments for MSVC. (Not that they get
used; As we are not cross-compiling with MSVC we will run the
typesconfig program for it.)
AC_SUBST also EXEEXT_FOR_BUILD and use that in Makefile.in.
As winemv.set.sh is now called WindowsMSVCEnv.Set.sh, with capital E
and S like all the others, we can simplify the glob pattern for the
Set.sh file.
Don't attempt to download and/or run unpackers for dependencies
relevant only when using MSVC if using MinGW.
Misc other Windows host vs. build fixes.
Still a long way from working, of course.
The configure script now runs to finish on Linux with --host=mingw32.
It is no longer an error if Windows SDK or DirectX SDK are not found
by the logic in the configure script. It might well be that the user
has included relevant -I and -L flags in CC or CXX that makes the
compilations work anyway, or something. We should not try to be too
clever and try to predict how the compiler or linker work in the
configure script.
We now define the FOO_FOR_BUILD environment variables in set_soenv.in
even when not cross-compiling (identically as the plain FOO ones in
that case, obviously). This should make some makefiles and stuff that
build tools to run on the build host a bit simpler.
We need to differentiate between compiling for Windows, and building
*on* Windows (which always means on Cygwin, actually). Fixed some of
those cases to use the proper test. cygpath should be used only when
building on Cygwin, naturally.
If attempting a MinGW cross-compilation it still doesn't even pass the
configure script without failing. Many hard problems have not been
solved.
Cygwin's gcc -mno-cygwin is generally considered a broken concepts, so
binning support for that. Instead, if on Windows but not using MSVC
one should use the Cygwin-based MinGW cross-compiler. That case should
probably not be considered as cross-compilation, though.
* Fix configure and download support
* Extension naming scheme is: <md5>-<extension-name>_<version>.oxt
- Renamed extensions
* Rename extension version number in download script and scp2 module
Signed-off-by: Fridrich Štrba <fridrich.strba@bluewin.ch>
Don't confuse the 64-bit Explorer extension with a 64-bit LibreOffice,
which is unfinished and highly experimental work. OOo has been
building and distributing a 64-bit Explorer extension since long, and
we should too. They used some secret Hamburg sauce when building it,
though, but hopefully now it works here, too.
* Fix configure and download support
* Extension naming scheme is: <md5>-<extension-name>_<version>.oxt
- Renamed extensions
* Rename extension version number in download script and scp2 module
The reason for the selective rejection of everything but a patched
ccache on Mac was broken objective-c/c++ support and a memory
corruption on arg parse - both are fixed on 3.0 and 3.1,
respectively. See http://ccache.samba.org/releasenotes.html
install to %libdir% intead of %prefix% as it is usual for other projects;
use the usual DESTDIR instead of OODESTDIR
Note that the default installation path is /usr/local/lib/libreoffice;
it can be redefined by --prefix, --libdir, --with-install-dirname
configure options
Some of these changes contributed by Petr Mladek <pmladek@suse.cz>
This is to allow use of ccache by specifying something like:
export CC="ccache C:/path/to/cl.exe"
export CXX="ccache C:/patch/to/cl.exe"
before running ./autogen.sh
as far as i saw the reason to use an absolute path for linking instead
of using -lpythonX.XX is that at least debian does not ship a shared
object within the basic python3 package so you have to install the -dev
package (that's kinda weird^H^H^H^H^Hf***ed up).
I did some initial testing with building under Interix some years
ago. Nothing came out of it, and LibreOffice certainly won't build
with it. But just commit this triviality now to get rid of
win32-interix.diff in the build repo.
- remove -pthread from PTHREAD_CFLAGS
- add pthread to gb_STDLIBS
- redefine gb_LinkTarget__command_dynamiclink so that we can
substitute -lpthread with -pthread in the list of libraries
that we link to
Solaris basename reports success for the empty string,
/usr/bin/javac is a relative symlink,
and by the way, the amazingly primitive Solaris 10 /bin/sh does not
understand $(), only backticks.
hopefully using readlink -f should work everywhere...
This breaks badly on pristine checkouts (that don't yet have the
other repos cloned, and symlinked into the src tree). Should only
be a prob for packagers, and they usually know what to do.
1. Do not add compiler default include and library path: potentially build
against different version of system library than requested by the user.
2. Add a configure option to disable Python2 (PyUNO) bindings. Python3 is
available for more than two years. Noone cares, therefore rest in peace.
Python2 is going to be ditched at some point. Simply do not fail then.
Windows builds need to be updated for BUILD_TYPE: "PYUNO". Or how is it
handled nowadays?
3. Fix sandbox violation in officecfg module: rm /bin/<language>.zip
4. Add a configure option to search only in one place for JVMs, which is quite
interesting for Linux Distributions. Enforce the user to place JVMs in one
base directory.
5. Fix build for libxml-2.7.8 with ICU support.
* config_office-XINC-XLIB-defaults.diff: (1)
* disable-python.diff: (2)
* gentoo-sandbox.diff: (3)
* jvm-search-path.diff: (4)
* libxmlsec_fix_extern_c.diff: (5)
* origin/feature/gnumake2.1: (202 commits)
Revert "starmath need to have _DLL_ defined, even on MacOS"
tweak library name on MacOS
starmath need to have _DLL_ defined, even on MacOS
add helper to set-up the libraries env, to run executable during build
the startmath module in Module_ooo must use the name of the directory
add starmath libraries to Repository.mk
make linkoo scan the solver too, for Norbert's gnumake work
-Wunitialized is not compatible with -DDEBUG
rename gb_HIRESTIME to gb_LOWRESTIME. Assume highres precision by default
add missing library for sc. Massage the delivered libraries name.
support USE_GMAKE=1 envvar to build with gmake the modules that can be.
add sc in the list of gmake-Modules
support for an alternate gbuild.lst to support gmake build
add a few comment to balance quotes, to make the editor less confused
add all the sub-directory of the RESLOCATION to search for resource
add calc related library to the Repository
tweak MacOs platform specific include to build on Macos
fixing variable exports for windows compiler (thanks ause)
fixing variable exports for windows compiler (thanks ause)
also accept debug=t
...
Conflicts:
Makefile.in
Module_ooo.mk
Repository.mk
RepositoryFixes.mk
configure.in
solenv/bin/build.pl
solenv/bin/modules/RepositoryHelper.pm
solenv/bin/packmodule
solenv/doc/gbuild/doxygen.cfg
solenv/doc/gbuild/solenv/gbuild/types.mk
solenv/gbuild/AllLangResTarget.mk
solenv/gbuild/BuildDirs.mk
solenv/gbuild/ComponentTarget.mk
solenv/gbuild/Deliver.mk
solenv/gbuild/Executable.mk
solenv/gbuild/Helper.mk
solenv/gbuild/Library.mk
solenv/gbuild/LinkTarget.mk
solenv/gbuild/Module.mk
solenv/gbuild/Output.mk
solenv/gbuild/Package.mk
solenv/gbuild/PrecompiledHeaders.mk
solenv/gbuild/SdiTarget.mk
solenv/gbuild/StaticLibrary.mk
solenv/gbuild/TargetLocations.mk
solenv/gbuild/gbuild.mk
solenv/gbuild/platform/linux.mk
solenv/gbuild/platform/macosx.mk
solenv/gbuild/platform/solaris.mk
solenv/gbuild/platform/windows.mk
solenv/gbuild/processdelivered.awk
solenv/gbuild/processdeps.awk
solenv/inc/unxgcc.mk
soltools/mkdepend/def.h
soltools/mkdepend/include.c
The SIZEOF_LONG and WORDS_BIGENDIAN tests failed anyway because CC has
already been set to point to MSVC, but no required include and library
paths got used in the tests. The large file support test is equally
unnecessary, Windows has large file support and no special compilation
flags are needed.
Just hardcode the known values of the substitution variables for
Windows.
