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

[Daniel Dunbar]

2009/12/7 Rafael Espíndola <rafael.espindola at gmail.com>:
>> 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.

No argument there. :)

>> 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? :-)

Presumably, but just to make sure we are on the same page I presume
you don't really care about relative paths but rather non-canonical
paths. A relative path can always be turned into an absolute path that
will behave the same, unless its being resolved in multiple contexts?

This has been implemented as -resource-dir, so that clang -cc1 should
get its resources dir relative to where the driver found itself. Let
me know if this works (or doesn't work) for you.

>>>> 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.

It's more a side effect of how GetMainExecutable is implemented than
an explicit decision. I do personally rely heavily on the ability to
make a symlink point to the actual compiler, but that works in the
model I outlined.

> 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.

The problem with argv[0] is it isn't always correct, and it may point
to a symlink. This is why I proposed recursively resolving symbolic
links via argv[0], in the cases when argv[0] isn't correct this will
fail immediately and we will fall to the canonical path

> Is there anything you would like me to implement?

If you want to cook up a patch that implements this strategy and
verify that it solves the original problem, that would be great. To
make sure we are on the same page, this is what I am imagining, in
untested pseudo-Python:

--
def getDriverDirsToSearch(argv0, mainaddr):
  while os.path.exists(argv0):
      yield argv0
      try:
        next = readlink(argv0)
      except:


      argv0 = readlink

--

> Cheers,
> Rafael
>