[BuildTools] Revised trunk/coin.m4 with --enable-doscompile

[Lou Hafer]

Andreas, Laci, et al.,

	I've pushed a revised coin.m4 into BuildTools/trunk, merging the version
I've been using with the most recent trunk revision.  But that doesn't actually
get it to the users.

	I've been using this coin.m4 with BuildTools/trunk and a custom-blended
Cbc/branches/devel (mix of trunk and branches/devel externals) since mid-Fall,
primarily with Solaris/Studio and Fedora/GCC, but it's had at least one test run
on SuSE/GCC, Solaris/GCC, Cygwin, Cygwin/Mingw, and Cygwin/MSVC.  (Mingw is
cygwin and GCC with --mno-cygwin, MSVC is cygwin and cl.)  Last night, I only
had time to test the merged version with Fedora/GCC, Cygwin, and Cygwin/Mingw,
using the BCP 1.1.0 release.  (As others have noted, cygwin is sooooooo slow
:-).  The first check was to drop the new coin.m4 into the release (no other
changes) and do a run_autotools, configure, make, make test sequence.  There's a
warning about sys/resources.h during configure, but the build and test works
fine.  Then it occurred to me that with the way we're using externals, this
wouldn't get Laci closer to generating a release for Tramezzi.  So I ran the
check again, dropping BuildTools/trunk into the release.  Also seems to work ok.

	That said, I don't make much use of the ThirdParty side of BuildTools.
Andreas, you'll have a better handle on the stability of that part in the trunk.

	So ...  Laci, if you're feeling a little daring, and Andreas concurs,
the best approach to getting a fix to Tramezzi might be to generate a new
release using BuildTools/trunk.  Otherwise, it'll be a matter of generating a
tarball with regenerated configure scripts and sending it to him as a patch.

	Then we should consider when/if we want to move this over into
BuildTools/stable and upgrade other projects.  Andreas, I didn't scan the
repository to see if the libtool reuse macros have been pushed into stable.  We
might want to consider them at the same time.

							Lou