Adapt some of the DLL names to match conventions we currently use in a
MinGW build. If those are changed to be exactly like when built with
MSVC (for SDK ABI stability reasons), will have to change here, too.
Bypass stuff that we can't build with MinGW when necessary. Should be
synchronized with the corresponding makefiles, obviously. We can't
currently build the Explorer extension or MSI installer custom actions
with MinGW due to lack of some required headers and/or import
libraries.
Surely these are linked to by default anyway? Is this just old cruft,
or specific to OOo's use of MinGW on Cygwin, and not needed with a
modern mingw-w64 cross-compiler? Let's see...
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.
It was supporting both XPropertyTable & XPropertyLis. XColorTable is now
based on XPropertyList and it was the only on that was based on the Table
class.
TODO: we might be able to remove some of the "if(mpList)" statements; this
needs more research.
