[Top][All Lists]

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

Re: [PATCH] Ignore boilerplate logo from MSVC on stderr.

From: Peter Rosin
Subject: Re: [PATCH] Ignore boilerplate logo from MSVC on stderr.
Date: Thu, 18 Nov 2010 23:15:21 +0100
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20101027 Thunderbird/3.1.6

Den 2010-11-18 22:17 skrev Paul Eggert:
> On 11/17/10 21:47, Peter Rosin wrote:
>> If you take some random proprietary compiler on some
>> random proprietary unix, you expect autotools to cope.
> No, actually, I don't expect that.  For example, on Solaris 10, I
> must pass some arguments to 'configure', or otherwise I won't
> be using the proprietary compiler, or I'll be compiling
> in 32-bit mode when I obviously want 64-bit, or I'll be
> linking to the wrong libraries, or whatever.  It's pretty
> common, actually, that some arguments will be required to
> get a proper build on Solaris.  It shouldn't be surprising
> that arguments might be required for a Microsoft environment
> too.

I was not suggesting that autotools would work "perfectly" for
every unix/compiler out there without feeding a bunch of directions.
See my comment about "elbow grease", another name for the extra
effort needed to find out quirky options for configure (or other

I'm also not suggesting that *no* configure arguments are allowed
for MSVC operation to be "acceptable", I just thought this particular
issue was low hanging fruit, which it apparently isn't.  At least not
for me.

I was trying to say that the expectation is that if I just find
the right configure magic, I can get a unix+compiler to work,
which is about the same thing you said.  I then went on to suggest
that other people would perhaps not expect to be successful with
MSVC no matter how much they try to permute (or even pervert) the
configure invocation.

This difference in mindset when trying to build a package is
what I'm getting at, as I think people will give up more quickly
when they attempt a MSVC build, as it surely can't just work...


reply via email to

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