[PATCH] D13642: [Bugpoint] Allow fallback to clang
Davide Italiano via llvm-commits
llvm-commits at lists.llvm.org
Wed Oct 14 08:33:52 PDT 2015
On Wed, Oct 14, 2015 at 8:31 AM, Davide Italiano <davide at freebsd.org> wrote:
> On Wed, Oct 14, 2015 at 6:02 AM, Rafael EspĂndola
> <rafael.espindola at gmail.com> wrote:
>>>> + // Try to fall-back to clang if the user didn't pass GCC as option.
>>>> + if (GCCBinary == "")
>>>> + GCCBinary = "clang";
>>>> +
>>
>> I was actually thinking of
>>
>> if (GCCBinary.empty()) {
>> if (gcc exists)
>> GCCBinary = "gcc";
>> else
>> GCCBinary = "clang";
>> }
>>
>
> I don't mind changing that as you request but is there a real reason
> why we can't use clang if available and the user doesn't specify GCC?
> The only one I can think of is that this changes the default, and may
> be potentially a POLA violation, but is this something really
> important?
>
To be more precise, I'd rather prefer:
if (GCCBinary is not specified) {
if (clang exists)
GCCBinary = "clang";
else
GCCBinary = "gcc";
}
>>> This is still a little bit weird because all the variables have GCC as prefix.
>>> If you're fine with this, I'll do a sweep and rename all of them. I
>>> thought about 'CCBinary, class CC' rather than 'GCCBinary, class GCC'
>>> etc.. but I'm open to new suggestions.
>>
>> It is OK to rename it, but lets do it in another patch.
>>
>
> Are you fine with 'CCBinary' or do you prefer something else?
>
> Thanks,
>
> --
> Davide
>
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
--
Davide
"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare
More information about the llvm-commits
mailing list