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

On Mon, Aug 29, 2005 at 06:15:04PM -0600, Warren Young wrote:
> Just the fact that the command is "makemake vc" tells you 
> that someone, somewhere put some thought into the Visual C++ case.

That's quite true.


> >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.
> 
> If documentation is the only problem, I think I've proven that I can 
> handle that.

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. :-)


> 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'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. :-)


> >keeping the build process simple.
> 
> 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.

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.


> 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.

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?unsub=gcdmc-plusplus@xxxxxxxxxxx