Actually NSIS_PATH is crack, it is actually the *directory* where the
makensis program is located, so why not simply just have a variable
with the full pathname to that instead (or just the command name, in
case it is in the default PATH anyway, like on openSUSE with
/usr/bin/makensis)? That would simplify the stuff in download.pm, too.
* also change GNUMakefile.mk to find the RepositoryModule_*.mk, instead of Module_*.mk
* subsequenttests was broken by the introduction of tail_build, because there where two Module_*.mk in root
* addendum to commit 99079f03d95d525e7e95a56569c37094618fb2ca
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.
* also change GNUMakefile.mk to find the RepositoryModule_*.mk, instead of Module_*.mk
* subsequenttests was broken by the introduction of tail_build, because there where two Module_*.mk in root
