| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
- tested locally that dmake is able to run with -P14 and that
icecream is then using more slots (checked with icemon)
|
|
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.
|
|
== is not portable, not even GNU coreutils test(1) supports it.
|
|
|
|
|
|
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.
|
|
|
|
|
|
which does not yet exist though
|
|
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.
|
|
It's called the Windows SDK, not the Platform SDK. Link only with the
ws2_32 library, not the wsock32 one.
|
|
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.
|
|
|
|
|
|
No idea in what circumstance one would want to use that.
|
|
|
|
|
|
|
|
|
|
And some baby steps for cross-compiling for iOS in particular.
|
|
|
|
|
|
It's called the .NET Framework, so don't talk about "frame".
Also align Usage help printout better.
|
|
|
|
|
|
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
|
|
and default is dev build
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* configure.in:
|
|
|
|
|
|
OxygenOffice related
|
|
|
|
|
|
cannot use the same variable for two AC_PATH_PROG calls, as the first call
will cache the result and the second one will reuse it
|
