On 09/09/14 00:26, Russ Allbery wrote:
> Bastien Chevreux writes:
>> Would it be worthwhile to forward this to the GNU compiler maintainers
>> so that they could maybe correct their course by maybe introducing a
>> define which is ‘reserved’ for telling that, yes, this is indeed a GNU
>> compiler?
On 09 Sep 2014, at 1:33 , Peter Johansson wrote:
On 09/09/2014 04:36 AM, Bastien Chevreux wrote:
>> is there somewhere in the autoconf system a macro which gives back the
>> compiler family of the used compiler so that one can take some action?
>> Something which would set a variable (e.g. COMP
Bastien Chevreux writes:
> And that’s the point: as a developer of a program who uses a compiler
> just as a mean to get things done, I’m totally not interested in this …
> and I shouldn’t. It’s enough for me to know that a given compiler is
> buggy between version X and Y when a given flag is us
On 09/09/2014 04:36 AM, Bastien Chevreux wrote:
is there somewhere in the autoconf system a macro which gives back the
compiler family of the used compiler so that one can take some action?
Something which would set a variable (e.g. COMPILER_FAMILY) so that one can
write something like this:
Bastien Chevreux writes:
> Would it be worthwhile to forward this to the GNU compiler maintainers
> so that they could maybe correct their course by maybe introducing a
> define which is ‘reserved’ for telling that, yes, this is indeed a GNU
> compiler?
That's what __GNUC__ was for. However, fr
Bastien Chevreux
> OK, before this duck thing gets a bit out of hand...
Oh, it's *way* too late for that :-).
> I would need to test whether the compiler accepts ?-OMG?
> AND
> I would need a way to test whether the compiler is specifically GCC (not
> clang, not icc) between 3.2.0 and 3.4.2
>
On 08 Sep 2014, at 23:38 , Marko Lindqvist wrote:
> Maybe gcc regression test set has a bit lighter test added against
> the bug in question, added when it was fixed.
If only one knew exactly which one of the bugs or features they fixed it was.
There are dozens/hundreds, digging through all poss
On 9 September 2014 00:25, Bastien Chevreux wrote:
> On 08 Sep 2014, at 23:07 , Marko Lindqvist wrote:
>> I'm ginving theoretical autoconf-way answer. I admit that in some
>> individual cases the Right Thing(tm) might be too much work in
>> practice, and the "check version number" hack is justifi
On 08 Sep 2014, at 23:07 , Marko Lindqvist wrote:
> I'm ginving theoretical autoconf-way answer. I admit that in some
> individual cases the Right Thing(tm) might be too much work in
> practice, and the "check version number" hack is justifiable.
Indeed it may be. Delivering the source code with
On 8 September 2014 23:51, Bastien Chevreux wrote:
> On 08 Sep 2014, at 22:30 , Marko Lindqvist wrote:
>> On 8 September 2014 22:34, Bastien Chevreux wrote:
>>> Down Under there are mammals who got pretty good at imitating duck features
>>> lately.
>>
>> That's exactly the reason for autoconf-w
On 08 Sep 2014, at 22:30 , Marko Lindqvist wrote:
> On 8 September 2014 22:34, Bastien Chevreux wrote:
>> Down Under there are mammals who got pretty good at imitating duck features
>> lately.
>
> That's exactly the reason for autoconf-way:
> […]
OK, before this duck thing gets a bit out of ha
On 8 September 2014 22:34, Bastien Chevreux wrote:
> Down Under there are mammals who got pretty good at imitating duck features
> lately.
That's exactly the reason for autoconf-way:
checking for duck ... no
Configure failed! Needs to be able to swim, and you've got shark.
vs
checking f
Bastien Chevreux :
> Which brings me to what sparked my initial mail to the list: is there
> somewhere in the autoconf system a macro which gives back the compiler family
> of the used compiler so that one can take some action? Something which would
> set a variable (e.g. COMPILER_FAMILY) so tha
On 08 Sep 2014, at 20:57 , Paul Eggert wrote:
> On 09/08/2014 11:36 AM, Bastien Chevreux wrote:
>> Which brings me to what sparked my initial mail to the list: is there
>> somewhere in the autoconf system a macro which gives back the compiler
>> family of the used compiler so that one can take s
On 09/08/2014 11:36 AM, Bastien Chevreux wrote:
Which brings me to what sparked my initial mail to the list: is there somewhere
in the autoconf system a macro which gives back the compiler family of the used
compiler so that one can take some action?
That would not be The Autoconf Way. :-)
T
On 08 Sep 2014, at 18:37 , Marko Lindqvist wrote:
>> Maybe it's as simple as patching autoconf to change the message to
>> "checking whether the compiler understands GNU C extensions", to match
>> the reality of how it works these days.
>
> The $GCC example brings up another problem, though. Even
On 09/08/2014 09:37 AM, Marko Lindqvist wrote:
Is there need to update documentation
abour $GCC to say that it should not be taken literally, but just to
mean some kind of gcc compatibility.
Thanks, good suggestion. I installed the attached patch.
>From ae3551f8d136968d18cac50810355d4160fa0427
On 8 September 2014 17:29, Eric Blake wrote:
> On 09/08/2014 02:44 AM, Thomas Jahns wrote:
>> On 09/08/14 06:24, Paul Smith wrote:
>>> In particular, this:
>>>
>>> configure:3666: checking whether we are using the GNU C compiler
>>> configure:3685: clang -c -mmacosx-version-min=10.6conftes
On 09/08/2014 07:29 AM, Eric Blake wrote:
Maybe it's as simple as patching autoconf to change the message
Thanks, good idea. I installed the attached.
>From db9a848f1042ae17ddbf85ba66a970998746a0d0 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Mon, 8 Sep 2014 09:25:08 -0700
Subject: [PATCH
On 09/08/2014 02:44 AM, Thomas Jahns wrote:
> On 09/08/14 06:24, Paul Smith wrote:
>> In particular, this:
>>
>> configure:3666: checking whether we are using the GNU C compiler
>> configure:3685: clang -c -mmacosx-version-min=10.6conftest.c >&5
>> configure:3685: $? = 0
>> configure:36
On 09/08/14 06:24, Paul Smith wrote:
> In particular, this:
>
> configure:3666: checking whether we are using the GNU C compiler
> configure:3685: clang -c -mmacosx-version-min=10.6conftest.c >&5
> configure:3685: $? = 0
> configure:3694: result: yes
>
> Appears to show that clang is
On Sun, 2014-09-07 at 22:52 +0200, Bastien Chevreux wrote:
> having used gcc for ages, I decided to try and play around with clang
> for one of my C/C++ projects. Unfortunately, it looks as if autoconf
> 2.69 gets things horribly wrong with clang.
In what way? IIUC, configure has discovered that
Hello there,
having used gcc for ages, I decided to try and play around with clang for one
of my C/C++ projects. Unfortunately, it looks as if autoconf 2.69 gets things
horribly wrong with clang.
I’m literally forcing it to find only clang, but it still insists on trying to
tell me I’m running
23 matches
Mail list logo
