Re: VC++ users: new proposed requirement for GNU make

Chris Frey wrote:
> On Windows, there is (I hope) native GNU Make,

I did some searching, but couldn't find one.  I did find a version of 
GNU make 3.78.1 (from 1999!), but it seems to have been built with 
MinGW, possibly before the MinGW project really got its ducks in a row. 
 The success of MinGW and Cygwin is probably why VC++-built versions 
are difficult to come by.

> MingW (make there?), 

Yes, the MinGW project offers a version of GNU make.  I think this 
counts as "native GNU make" in all significant aspects anyway.  I don't 
see any functional differences that a VC++-built version would have.

> and Cygwin's make which introduces trouble of its own with special path setups.

I see your point.  I think the proper reaction to this reality is to 
ensure that the resulting Makefiles work with both the MinGW and Cygwin 
versions of GNU make.  If we can't ensure that, we should indeed ask 
ourselves whether we shouldn't scrap the idea.

> I'd start looking at setting makefile variables with the target directory
> on the nmake command line or environment, and calling it twice.

Getting cl to put output files in a different directory is easy. 
Getting make to look at files in that directory when figuring 
dependencies is the tricky part.  You can do this with GNU make using 
the VPATH feature, which nmake doesn't support.

That's why the current version of MySQL++ only puts the release binaries 
in a separate directory: there has to be at least one set of binaries in 
the same directory as the sources for dependencies to work correctly at 
all.  In fact, it's a rather dirty hack, because if for some reason the 
release binary is out of date but the debug version is not, the current 
makefiles won't detect this.  One way to get into this state is to hit 
Ctrl-C after a debug obj is built but before the release one finishes 
building.  I Ctrl-C out of a build process all the time when I see a 
warning that I want to fix before moving on.

>         VC6 project     - Someone who cares!

There won't be a VC++6 project, ever, because the C++ language subset it 
supports is far too limited.  That's why I have to carry the ancient 
1.7.1 version.  Even 1.7.9 won't build on VC++6.

I'm tempted to remove it, but I just grepped the logs, and I've had 
hundreds of downloads of it just in the recent past.  _Someone_ 
apparently still wants it.

>         VC7 project     - Someone who cares!

Ah, "someone who cares"...exactly the problem.

I don't know if you've noticed, but I think you and I are the only two 
people consistently active over time on this project.  Everyone else 
seems to disappear after a while.  (Anyone who thinks I'm missing their 
long-term contribution, please speak up...I don't mean to not recognize 
you.)

If I'm right, it won't be "someone who cares".  It will have to be a 
succession of people who care.  Meanwhile, I've kicked a few of the 
supports out from under the demand curve by providing an alternate, 
supported mechanism, so these people will be increasingly hard to find.

> These files would be updated on a complaint basis.  Those that care would
> get notice to update their files during the "release candidate" announcement,

Another thing you may not have noticed: we've gotten more complaints and 
bug reports in the two weeks that v2.0 has been available than in the 
two months that v2.0 was in development.  I haven't groused publically 
about this because I knew it would happen -- I predicted it in the v2.0 
plan announcement, in fact.

I'm not complaining.  I'm just saying that it's foolish to count on 
working all bugs out during the RC phase.

> This does sound good, but could get messy, reverse-engineering Microsoft
> project files.

I seem to recall that the VS6 project files were binary ugliness, but 
since VS7 they're straightforward XML.  I wouldn't have suggested it 
otherwise.  Recent Borland project files are XML, too, by the way.

One way to do this is to somehow export the knowledge from the autotools 
output in an intermediate format, then translate that to XML.  Another 
way would be to somehow make these XML project files a target from 
within automake so the translation is direct.  Both are tricky.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=gcdmc-plusplus@xxxxxxxxxxx