The recent changeover to the makemake system hasn't been received
uncritically. Some of the problems people have with it could be fixed
if I mandated the use of GNU make. It allows Makefiles that are much
more expressive than supported by Microsoft's nmake.

There are several sources for GNU make for Win32, so I don't see how
anyone can claim this prereq as a hardship. If you disagree, let me
know...I'm not set on this course yet.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Mon, Aug 29, 2005 at 12:21:26PM -0600, Warren Young wrote:
I can see it as a hardship, and I don't even use mysql++ on VC++. :-)

When I want to build something on windows, say bochs or VNC for example,
it's always a huge relief to see VC++ project files available, since it
indicates somebody has already been down that path before.

When someone has been down the path of the windows toolchain, things just
work, at least in my experience. When you need special build tools,
a GNU tool chain, or something external, it is often not documented well,
and there are problems down the line.

Have you ever tried to build mozilla on windows? It's a freaking
nightmare. :-) I've banged my head against that build process a few
times, and still haven't gotten it to build, even with the official
release tarball. (!) This build process has stopped me from even attempting
to work on a simple feature. No sense to code if I can't build it.

Admittedly, mozilla is much larger than mysql++, but I think it
illustrates the point of keeping the build process simple.

Just my $0.02... as I don't use mysql++ on windows (yet), take with
a chunk of salt. :-)

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
I could see that view if we were shipping generic Makefiles...back
before autotools, most open source projects had just a single Makefile
and you'd have to edit it just to get the thing to build. (Assuming it
would build out of the box at all...) makemake isn't as powerful as the
autotools, of course, but it's a lot better than the scenario I just
described. Just the fact that the command is "makemake vc" tells you
that someone, somewhere put some thought into the Visual C++ case.

If documentation is the only problem, I think I've proven that I can
handle that.

What I _can't_ handle is implementing every little feature people want
using inadequate tools. Here's a challenge for you: someone asked for
separate release and debug binary directories. Implement _that_ using
just a single nmake-compatible Makefile, without duplicating the entire
structure for both cases. I can do it in GNU make no problem.

I don't know if you've noticed, but the latest edition of O'Reilly's
make(1) book is GNU-specific. They no longer even bother covering the
old tools that inspired GNU make. Only the trivial examples in chapter
1 will even run on anything but GNU make.

Face it, GNU make has won. Only question is, who doesn't know it yet?

It's not like I'm suggesting Jam or something like that here...

So I won't make it difficult, then.

There will always be newbie problems, Chris. We have people here
posting to the list because they don't have the MySQL development files
installed for Bob's sake. There's a point where more help just isn't
helpful to anyone.

I can go with that, too, but along with it, you get fewer features. And
that's exactly the source of most of the complaints of makemake.

And no, don't tell me to go back to project files. Won't happen.
They're fine anywhere you have just one tool chain and can mandate a
particular version of it. Beyond that, fuggedaboutit.

Actually, there's one exception. It would be Really Neat (TM) if
someone wrote a tool that would work with autotools to auto-generate
project files for VC++ and such. Could be done. But not by me this week.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Mon, Aug 29, 2005 at 06:15:04PM -0600, Warren Young wrote:
That's quite true.


The problem I see in the Windows world is that there is no consistency
across build tools except for VC++ itself.

On Windows, there is (I hope) native GNU Make, MingW (make there?), and
Cygwin's make which introduces trouble of its own with special path setups.

From what I've seen of these tools, they have klunk written all over them from
the user's point of view. But I've been looking at this from the wildly
scary mozilla build process, so I may be biased. :-)

That said, a native GNU Make requirement, by itself, is probably not
that bad. :-)


I'd start looking at setting makefile variables with the target directory
on the nmake command line or environment, and calling it twice. But as
I'm not a heavy mysql++ windows user, go with GNU make. :-)


I know I should forget about it, but here's an idea. :-)

How about we handle different build options in the same way we handle
package creation? On a volunteer basis. We would need a contrib/
directory for these files, with email addresses attached to each, so
people know who to complain to. Currently we have:

rpm.spec - You're the maintainer
Gentoo ebuild - I'm the maintainer... I've got no complaints yet,
but it might be worth labeling me clearly as the
guy to pester

We could add:

debian rules - I could do that too, but it's been a while
VC6 project - Someone who cares!
VC7 project - Someone who cares!
etc.

These files would be updated on a complaint basis. Those that care would
get notice to update their files during the "release candidate" announcement,
and if nothing happens, they don't get changed. Future people who are
interested have a place to start from, and pick up the torch.

In this way, non-GNU Make build options are second rate citizens,
but at least they are citizens. And it takes the load completely off you.
You just apply a patch if the maintainer sends it.


This does sound good, but could get messy, reverse-engineering Microsoft
project files. Distributing the load to volunteers seems easier, but
maybe I don't see how full your mailbox is. :-)

- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

i would prefer having vc build process , too.
It's just i know this way is working and i don't have to use one more
compiler where i don't know to get help when stuck...
Anyway this is just my opinion


Chris Frey schrieb:
--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
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.

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.

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.

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.

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.

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.

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.

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?unsu...ie.nctu.edu.tw

Thomas Werth wrote:
What makes you think the VS IDE uses a different compiler?

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

On Tue, Aug 30, 2005 at 06:37:19PM -0600, Warren Young wrote:
Whoops. Well, that's one dependency down. :-)

It is a amazing how long VC6 hangs on. The IDE is better than VC7,
in my opinion, and less buggy when it comes to handling resources,
which might be why.


Well, if those people are harder to find, then your build system works,
even with GNU Make.

I don't think anyone is going to step up to the plate to help you
wrestle NMAKE into submission just to avoid GNU Make. So on that side
of the argument, I agree, make GNU Make the default supported tool.

I do think that someone would be likely to contribute or update a VC7
project file, as this is something a windows developer is familiar with,
and only needs some GUI work. So I still like my contrib/ directory idea.

I'll even maintain that directory so you can ignore it completely, if you
like, and be the contact person for project files and package build
scripts, so even a "string of volunteers" can contribute through me.


That happens on every project, as far as I know. Must be some
trait in human psychology.

Personally, I stopped using my private CVS tree around the time that
SVN was setup. Looking back, that might have been a mistake, since I
didn't feel I had the same freedom to mess around and experiment with
the SVN account. I've started putting release tarballs back in my CVS,
just to help me track and experiment.

Plus, I couldn't keep up with you... there's 239 new commit messages
still in my mailbox that I haven't even looked at, and my methodical
methods don't mesh well with that. :-)


- Chris


--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Chris Frey wrote:
I won't try to stop you if you do this, but I will admit to being a
little annoyed by it. But programmers being annoyed by "the users" is
normal, so don't mind me.

I just thought of another reason makefiles are superior, at least for
MySQL++: you have to drop to a command line to run the examples anyway.
What's the point of going to the trouble to build everything in the
GUI if you can't effectively test things there? Yes, you could put
breakpoints at the end of main() on all of the examples, and set the
Debug | Run settings for your system, but...ick. Command lines are
still superior for many things.

As long as you put your hackery on a separate branch, I don't care.

It's been useful in the past for you to check my work, but I hope you
don't feel compelled to do it. A lot of the proposed changes for
MySQL++ are quite parallelizable, especially now that we've gotten all
the major archtecture changes out of the way for a while.

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw

Warren Young schrieb:
I'm afraid to need new subsystem like cygwin or mingw with new make
syntax where in case i need personal adaption i'm sitting right in
middle of nowhere...
But anyway if you'll get it with gnu make so user need only to call
makemake vc i'm sure to get his managed
Maybe some kind of deploying like metasploit would be able where
cygwin(?) is deployed in same tar ball would be nice.
( As i'm user ( no developer ) it's natural to request silly features )

--
MySQL++ Mailing List
For list archives: http://lists.mysql.com/plusplus
To unsubscribe: http://lists.mysql.com/plusplus?unsu...ie.nctu.edu.tw