This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: how to distinguish patched GCCs
On Fri, May 27, 2011 at 11:02 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 27 May 2011 09:46, Matthias Kretz wrote:
>>>
>>> The cases where you have to work around compiler issues in a
>>> _header_ file should be very rare.
>>
>> And? Because they are rare we shouldn't care? I'm developing a template
>> library for SSE, AVX, LRBni, ... and this stuff is like daily bread for me. So
>> I'm surely a special GCC user here...
>>
>> But this SIMD stuff is hard to understand and my library is supposed to make
>> it easier for average developers. I think my API reaches that goal, but
>> compiler availability and compiler bugs almost negate that again. So one of my
>> major goals is to make it just work as good as possible with any given
>> compiler. It's just plain hard to impossible ATM. This simple macro would be
>> of major help. At the same time I don't see any downsides, do you?
>
> It's an additional maintenance burden.
>
> And when a vendor doesn't use the macro or uses it "wrong" (for your
> purposes) you still need to rely on configure checks to see what
> actually works with a given compiler.
Indeed. I think it won't work in practice.
I know developing on the edge of what compilers support can be a PITA,
but it's more maintainable to have checks and workarounds in terms
of actual bugs than compiler versions. It should be relatively easy for
you to provide a my-library-config.sh that provides the defines for
an installed copy and the current compiler - much similar to what
was done in pre-pkg-config times. So, teach your users to put
CXXFLAGS=$(CXXFLAGS) `my-library-config.sh $CXX`
in their Makefile and they will get your library configured at build time
of the client app.
Richard.