lmi
[Top][All Lists]
Advanced

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

Re: [lmi] PATCH: tests build fixes for clang


From: Greg Chicares
Subject: Re: [lmi] PATCH: tests build fixes for clang
Date: Sun, 7 Mar 2021 15:25:57 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 3/7/21 1:10 PM, Vadim Zeitlin wrote:
> 
>  I'd like to submit a series of small fixes to the tests allowing to build
> them with clang, please see https://github.com/let-me-illustrate/lmi/pull/173

I glanced quickly at the commit messages, and each seems to be a
valuable improvement. Of course, the larger goal of supporting
clang is most valuable.

>  One thing I did _not_ do, although I think it would be worth doing, was to
> define LMI_GCC and LMI_CLANG macros in config.hpp. The reason I'd like to
> do this is that the number of occurrences of
> 
>       #if defined __GNUC__ && !defined __clang__
> 
> tests increases from 4 to 10 with this PR and it risks continuing growing
> in the future, so I'd prefer to write this as shorter and clearer
> 
>       #if defined LMI_GCC
> 
> instead. If you agree that it would be a good idea, please let me know and
> I'll add a commit doing this to this PR (or create another PR with it, as
> you prefer).

Sounds good. Would you prefer to do that before I merge PR 173,
or should I merge PR 173 as it stands now?

>  Just for completeness, another possibility I've considered was to define
> the existing LMI_GCC_VERSION only for "genuine" gcc, but I don't think it's
> a good idea because:
> 
> 1. The existing uses of LMI_GCC_VERSION should be removed[*] in the first
>    place as they're very obsolete (some check for gcc 3.2!).
At a quick glance, it looks like at least one might guard some
code that revealed a compiler defect. Sometimes a defect seen
in one compiler in one year later appears in a later year with
a different compiler, so I'm pretty conservative about removing
conditional workarounds. But I'll take a look at every instance.


reply via email to

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