automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: call for help/crazy idea: nmake support


From: Bob Rossi
Subject: Re: call for help/crazy idea: nmake support
Date: Tue, 3 Aug 2010 10:36:13 -0400
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

(This bounced the first time I sent it, sorry if it reposts)

On Sat, Jul 31, 2010 at 01:41:29PM -0700, David Byron wrote:
> On Saturday, July 31, 2010, Ralf Wildenhues wrote:
> 
> > Here's a crazy idea: how about if automake optionally
> > output an input file suitable for nmake (after configure
> > substitution)?  Is that even feasible?  (I'd guess so)
> > Maybe if we have contents conditional on 'make' or 'nmake'
> > output?  Would that even help anybody?  (no idea)
> 
> I don't think this would help that many people.  If someone is running
> autotools (or even a generated configure script) on windows, I think we can
> assume they've either got cygwin or msys which implies access to make.  If
> they've got make I can't see why they'd need to use nmake.

Yes, I agree. A few reasons off the top of my head,

There is a large audience of automake build systems that have taken
advantage of custom rules for specific make implementations (ie. gnu
make). These real-world build systems wouldn't port to nmake without
a lot of rework.

Also, it's been reported that using sh is much faster than using
cmd directly.
  http://labs.trolltech.com/blogs/2007/01/30/qtmsys/
  "It also turns out compilation using sh is way faster than using
  cmd.exe."
I'm guessing nmake uses cmd (that's strictly a guess), and would
probably be unnecessarily slow.

It's easy to get make/sh support via cygwin or msys these days,
so there is no real reason not to have it on windows (which is
the main target area for MSVC support). Also, you probably already
need this sort of support if you want to run configure.

> > Or is a better alternative to follow the path we have
> > taken with Libtool (finally getting MSVC support in) also
> > in Automake, with Peter's patches and more?
> 
> I like this approach much better.  All the hand-maintained versions of cccl
> would finally disappear.

Yes, this approach would benefit a lot of people, a lot faster. I
second this opinion.                                                            
                        

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]