NATIVE indicates that the BUILD and HOST platforms are the same,
i.e. a "normal" not cross-compiling build.
DESKTOP indicates a "normal" desktop/server OS, like Linux, Windows,
BSD or Mac OS X. (Non-desktop ones would be "mobile" ones like iOS and
Android.)
(All traditional, and so far only actually working, builds of OOo/LO
is both NATIVE and DESKTOP. The non-NATIVE and non-DESKTOP cases
belong in the experimental cross-compilation work.)
All non-DESKTOP cases are also non-NATIVE, at least so far. In other
words, when building for a mobile OS we always cross-compile. Note
that the reverse is not true: We eventually would want to
cross-compile to Windows, rarer Linux architectures, and PowerPC Mac
OS X.
DESKTOP is used in build.lst files to indicate modules that it makes
no sense to build for mobile platforms. Nobody is going to run
LibreOffice SDK tools on a tablet.
NATIVE is used in build.lst files to indicate modules that produce
just build-time executables (which can't be run on the BUILD system
when cross-compiling), and which are not part of the SDK either.
(Sadly the use of BUILD_TYPE keywords in the build.lst files is a bit
tedious: you have to mark a module in the build.lst files of all its
"parents", modules that depend on it, not in that of the module
itself.)
It does make sense to build SDK tools in the other cross-compilation
cases. There is no reason why we wouldn't want to cross-compile also
the executables that go into the SDK when cross-compiling to Windows,
for instance.
When we get so far (if ever) that it actually makes sense to build
some testing app, or (gasp) even a "useful" app, either for the
simulator or device, it needs to be done in Xcode anyway, just linking
with the libraries built here.
At least, that's my current understanding.
So no need to say "this will modify the solver", especially as that
talk about 'the' solver is Hamburg-speak.
Also, don't advice to use the -s (silent) flag to make. Once the
developer grows tired of seeing verbose output, he will learn to use
-s.
Removed mail module from installer subdirectory. I also removed code
that referenced the functions within this module (such as one
that sent a message if the process failed, one that sent a message
if the process succeeded, etc.)
