| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Why make life harder on purpose? On Cygwin, we support the Cygwin
Perl, period.
|
|
|
|
|
| |
For instance: If we have /opt/lo/bin in PATH already in front of
/usr/bin, we don't want to put /usr/bin in front of it again.
|
|
|
|
|
|
| |
It would be a weird PATH otherwise. (And if that is the case,
presumably there is a good reason for it, then, and we shouldn't force
/usr/bin there.)
|
|
|
|
|
|
|
| |
I don't see the need to explicitly prefix PATH with /usr/bin in the
generated 'bootstrap' file. Surely /usr/bin is in PATH anyway for any
sane setup, and if there are other directories in front of it in PATH,
that is then on purpose.
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit bf0ea5c4eefa122febaaa5e6da8ecf4b1869f991.
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.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's better to use two completely separate source trees than to try to
build two different versions of LibreOffice in the same one
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
| |
|
|
|
|
| |
It was reintroduced with a merge from the 3.4 branch
|
| |
|
|
|
|
|
| |
It doesn't make sense to try to use anything else to print on *nix
systems these days
|
|
|
|
|
| |
This commit enables LTO for all shared libraries.
Build takes much longer. Use just with gcc-4.5 or later.
|
| |
|
|
|
|
| |
This fixes the build of 'basic' on Windows.
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
* Added module
* Remove versioned directories in scp2 module for Lightproof
|
| |
|
| |
|
|
|
|
|
| |
Those were removed in commit 22d9caecc978a5739ddd1430fd26abe06454726c
already.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
Makefile.in
configure.in
instsetoo_native/util/makefile.mk
instsetoo_native/util/openoffice.lst
ooo.lst.in
set_soenv.in
solenv/inc/minor.mk
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
We do need to have the platform-specific part in WORKDIR, for
cross-compilation support.
This reverts commit 3c471c4a11fe58a6cd3dbf09099d9a1ecf60dd38.
|
| |
| |
| |
| | |
* this has been obsoleted with commit 22d9caecc978a5739ddd1430fd26abe06454726c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.)
|
| | |
|
|\ \ |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
As we build against the MacOSX 10.4 SDK we should certainly not link
against any libraries of the build OS, which could well be 10.5, 10.6
or 10.7.
Norbert verified that this works fine.
|