On Fri, May 27, 2011 at 11:02 AM, Jonathan Wakely <jwakely....@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.
