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.
