[cfe-commits] r90577 - in /cfe/trunk: include/clang/Driver/Options.td lib/Driver/Tools.cpp tools/driver/driver.cpp

Rafael Espíndola rafael.espindola at gmail.com
Mon Dec 7 11:06:45 PST 2009


> I view this as a symptom of it being a "bad idea". I really dislike
> providing command line options for this kind of thing -- its better to
> find a model where the compiler "just works".

Sure, it is just harder when you are trying to replace a tool that has
an existing interface.

> I intend to have clang pass the "resources path" to clang-cc/clang
> -cc1 fairly soon, we shouldn't need this option at the clang-cc level.

Nice! Will it support passing relative paths? :-)

>>> The main thing we
>>> are using this for is to find our "resources" (lib files and includes)
>>> -- what if we searched the following locations in order:
>>>  a. relative to argv[0]
>>>  b. relative to argv[0], following top-level links (NOT realpath)
>>>  c. relative to GetMainExecutable()
>>>
>>> I suspect this would solve your problem, and would also find the
>>> library directory much faster (than dladdr + realpath and friends) in
>>> the common case.
>>
>> I would not match gcc's behavior.
>
> Is that actually a problem? I'm not convinced these parts of gcc are
> well designed.
>
>> I am not sure if it might really be
>> a problem, but consider case where a resource can be found with "b"
>> but not with "a". I would like clang and clang-cc to produce an error.
>
> Is this important (the error)? Having a single consistent model is
> much friendlier to users (in the long run) than having multiple models
> and requiring an option. I think it is very unlikely that this lookup
> will (a) succeed and (b) find the wrong compiler; do you have a use
> case where that would happen?

I can make one, but I don't think it would actually happen for us. We
always set it up so that everything can be found via the symbolic
links. Note that header search has the same issue.

I am not sure if there is any user that depends on gcc's behavior of
using canonical dirs. Since clang and clang-cc are very careful to
always compute it, I assumed you guys did.

What is the usecase where a canonical path is necessary? Maybe we
could always use argv[0]? If not, lets try your suggestion of
searching argv[0] first and then the canonical path.

Is there anything you would like me to implement?

Cheers,
Rafael




More information about the cfe-commits mailing list