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.
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 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.)
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.)
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.
