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

[Laszlo Ladanyi]

How about the following:

Looks like a fair amount of change is in BuildTools/trunk. So let's create a
new stable version. Ask people to run configure/make/make tes on as many
platforms as they can by checking out the current stable version of a project,
changing its external (or just do a switch in BuildTools) and then do the
conf/make/etc. And let us know if there are errors. We can even provide a
script to do all the stuff. Shouldn't take more than half an hour to write the
script. This should shake down within a week. And if all goes well than all
projects can switch over to the new stable version of BuildTools. and create a
new tiny release.

What do you think?

BTW, If there are people who are willing to test *every* project then I can
write the script that way. Of course, someone needs to look through the
output, and that's the painful part :-).

--Laci

On Wed, 24 Jan 2007, Lou Hafer wrote:

> 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
> 
> _______________________________________________
> BuildTools mailing list
> BuildTools at list.coin-or.org
> http://list.coin-or.org/mailman/listinfo/buildtools
>