As an aside we can always use the configuration and data files belonging to the
system version now in --with-system-libexttextcat mode, so need for the --data
option.
This reverts commit bf0ea5c4ee.
Those variables are used in bin/distro-install-*.
Unable to find any issue with both distro-install and dev-install so
reverting.
If something really does break it needs fixing. Reverting this is not
an option.
Make sure the MINGW_FOO environment variables get set and propagated
to the build environment also in the MinGW cross-compilation case. The
OOo code used to do that for MinGW natively on Windows (under
Cygwin). (Which we don't intend to support.)
Now, whether the *use* of these variables in the various makefiles etc
is relevant any more remains to be seen. I suspect all that might well
be unnecessary, as we after all are capable of cross-build the code
using MinGW just fine currently with none of these MINGW_FOO being
set.
One place where at least MINGW_GCCDLL and MINGW_GXXDLL is needed,
though, is in scp2. We presumably do want to include these DLLs (the
shared libgcc and libstdc++) in the installation set, to the extent
the scp2 stuff can be used still in a MinGW cross-build context.
Its alternative values as used by OOo is irrelevant to us as we don't
intend to support building using MinGW on Windows itself. To us, MinGW
always means cross-compilation. For us it is enough to look at
$(OS)$(COM), and WNTGCC always implies cross-compilation.
(OOo on the other hand attempts to support use of the Cygwin gcc with
the -mno-cygwin option (which is practically considered an obsolete
option), the normal MinGW compiler (but still from Cygwin), but not
cros-compilation.)
The mozab code plays games with _DEBUG (undefining and re-defining it
around Mozilla headers), which causes linking error when part of the
code has been compiled with _DEBUG and part hasn't. See
connectivity/source/drivers/mozab/pre_include_mozilla.h. Just disable
Mozilla stuff for now when using --enable-dbgutil.
This commit allows to set which libraries to merge
and creates merged library in tail_build if enabled.
This should save time when loading libraries in application
and also makes more sense for link-time optimization.
Signed-off-by: Michael Meeks <michael.meeks@novell.com>
tail_build run mostly by itself and wrap a dozen of module,
using just MAXPROCESS for the parallelism force to limit NB_CPUS
in order to avoid a NB_CPUS x MAXPROCESS scenario.
This mitigate this problem, until we don;t need MAXPROCESS anymore
and NB_CPUS becomes the only driving force.
tml didn't like some of them; plus, configure.in -> configure removes the
[] in if statements (atleast on my machine) so I have to use "test".
My CPATH & LIBRARY_PATH statements where unreliable; even after modifying
set_soenv.in to export them correctly. I'm currently exporting them before
the ./autogen.sh && make and things seem to work better; I'm still looking
for a better solution.
Installing xCode 4.1 renames the xCode 3.2.6 directory to /Developer-old/;
however, the compiler gets confused and can't find the headers and libraries.
This patch just notifies the compiler where they are actually located.
Note: I'm assuming that people compiling on 10.7 aren't trying to generate
a PPC binary.
No longer call the script snippet LinuxX86Env.Set.sh,
MacOSXX86Env.Set.sh, etc, but always Env.Host.sh. No need for
source_soenv.sh then, which wouldn't have worked when cross-compiling
anyway.
(As before, when cross-compiling, the environment script snipppet for
the BUILD platform is called Env.Build.sh.)
generate en-US file list when --with-distro=""
sigh, we should set WITH_LANG=en-US when no language is selected; the empty
string is pretty ugly; unforrunately, many makefile tests check for
this empty variable
Signed-off-by: Michael Meeks <michael.meeks@novell.com>
Signed-off-by: Andreas Radke <a.radke@arcor.de>
Signed-off-by: Fridrich Strba <fridrich.strba@bluewin.ch>
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.
