[cfe-commits] Fix search path for clang on latest DragonFly releases [revised patches]

[John McCall]

On Dec 20, 2012, at 11:06 AM, John Marino <draco at marino.st> wrote:
> On 12/20/2012 20:02, Rafael Espíndola wrote:
>>> I am willing to work with you to improve dragonfly.c test, but I'm not
>>> willing to split the patch.   It's just absurd and it should not be split.
>>> I will update the patchset to fix USE_GCC47 and provide it with a
>>> "take-it-or-leave" banner along with the results of the check-all test.
>>> 
>>> If you choose to take it as given, fantastic.  If not, that's too bad, but
>>> you are not the only one contributing as a hobby.  Unfortunately we'll just
>>> have to keep patching downstream after each release in that case.  I
>>> apologize for my exasperated tone but this is a lot of busy work for no true
>>> gain.
>> 
>> I am not going to review a patch this big, sorry. I is just too easy
>> to miss something.
> 
> 
> Fine.  If 16 or so change lines is too much for you, I'll update the bugzilla report for historical reasons with the final patchset and maybe another clang developer will be able to do it.
> 
> Your fear is baseless because anything you miss only affects DragonFly and you know it.  Surely that much is obvious.

I apologize if you feel you've been getting a run-around.  Please ping me
when you post your latest patch to bugzilla, and I'll take a look.

The best way to ensure that dragonfly continues to build is to set up
a dragonfly LLVM/clang buildbot.  I think there at least used to be
one, but it might not be set up to test bootstrap.

The second best way to ensure that dragonfly continues to bootstrap
is to figure out every individual thing that was breaking bootstrap
before, fix it, and introduce a platform-independent test for that fix.
Having fixed code without tests is obviously better than having
broken code without tests, but if you want to make sure that your
code stays fixed, specific tests are critical.  Our code base evolves
quickly, and things do frequently get broken in refactors and rewrites
if they're not being adequately tested.

John.