[cfe-dev] LibTooling CMake Error

Sun Oct 21 13:09:30 PDT 2012

On Sun, Oct 21, 2012 at 8:40 PM, Mohammad Adil <madil90 at gmail.com> wrote:

> Hi,
>    I wish to share my humble opinion in this regard. I believe that clang
> is a great program and the Clang API is by far, the most self-explanatory
> API I have seen. Nevertheless, If clang is to ever replace gcc, it should
> offer a very smooth development. By forcing the user to place all tools in
> the clang directory, the project management is seriously hindered.
> Currently the paths in the json file are "../lib/clang/3.2/include". Why
> not simply replace them with the complete path like the rest of standard
> paths. Please consider my humble suggestion. It will be a lot of help for
> future development.
>

I'm not sure what the json files have to do with it. The json files just
describe compile options - the builtin header files really belong to the
tool executable.

>    As for now, Can you please tell me exactly where to place my tool? I've
> tried a few locations, but none of them seems to completely resolve the
> problem. I am very grateful for all of your help.
>

If you have a working <somepath>/clang binary of the same version as your
tool, with which you can compile code (and find the builtin headers ;)
place your tool into <somepath>/.

The easiest way to get your tool to work is to integrate it with the normal
clang build, the same way the extra-tools repository does.

Cheers,
/Manuel

>
> Regards,
> Adil
>
>
> On Sun, Oct 21, 2012 at 10:05 PM, Manuel Klimek <klimek at google.com> wrote:
>
>> On Sun, Oct 21, 2012 at 6:34 PM, Sean Silva <silvas at purdue.edu> wrote:
>>
>>> > I'm not sure what else could be done here. Ideas welcome :)
>>>
>>> Maybe we could bake those header files directly into libFrontend?
>>>
>>> It's a bit extreme, but I think that it is probably the right thing to
>>> do here, since to be honest, it is simply unacceptable for a library
>>> to force its clients to run their tool from directories with
>>> particular directory layouts, or to install in a particular place.
>>> Imagine if, say, zlib would not function correctly without a
>>> configuration file "../share/zlib/zlib.conf", or something like
>>> that---there would be outrage.
>>>
>>
>> Feel free to bring this up with Chandler / Doug on IRC. I've argued that
>> many times, and so far I've always lost (I don't remember all the points in
>> the arguments, but I think one big point is: you wan to have headers with
>> paths people can actually look at in their text editors).
>>
>> Cheers,
>> /Manuel
>>
>>
>>
>>>
>>> -- Sean Silva
>>>
>>> On Sun, Oct 21, 2012 at 5:13 AM, Manuel Klimek <klimek at google.com>
>>> wrote:
>>> > On Fri, Oct 19, 2012 at 11:09 PM, Mohammad Adil <madil90 at gmail.com>
>>> wrote:
>>> >>
>>> >> Thnx a lot for your help. Is there any chance this will be resolved
>>> soon?
>>> >> So, basically, there is absolutely no way in which proper paths for
>>> C++ can
>>> >> be added without hardcoding right now? I cloned the standard clang
>>> >> repository right now. Is there a development branch that might be more
>>> >> up-to-date?
>>> >
>>> >
>>> > clang-tool behave the same way clang does here - they need to find
>>> their
>>> > builtin includes; by default, the tools find those in
>>> > ../lib/clang/<version>/include.
>>> >
>>> > There are two ways to solve this problem:
>>> > 1. copy the tool you wrote next to the clang binary you built from the
>>> same
>>> > source tree
>>> > 2. create an "installation" of your tool, where
>>> > ../lib/clang/<version>/include points to the builtin headers
>>> >
>>> > I'm not sure what else could be done here. Ideas welcome :)
>>> >
>>> > Cheers,
>>> > /Manuel
>>> >
>>> >>
>>> >>
>>> >>
>>> >> On Sat, Oct 20, 2012 at 1:39 AM, Sean Silva <silvas at purdue.edu>
>>> wrote:
>>> >>>
>>> >>> > I checked the directories using -v and two directories namely
>>> >>> > "../lib/clang/3.2/include" and "/include" were not found. As you
>>> can
>>> >>> > see,
>>> >>> > these paths are wrong. They should be "/usr/local/lib/clang.." and
>>> >>> > "/usr/include". How can I fix this?
>>> >>>
>>> >>> This is the issue that I warned you about in the other thread, and it
>>> >>> has no solution to my knowledge except for hardcoding the correct
>>> >>> path.
>>> >>>
>>> >>> -- Sean Silva
>>> >>>
>>> >>> On Fri, Oct 19, 2012 at 11:33 AM, Mohammad Adil <madil90 at gmail.com>
>>> >>> wrote:
>>> >>> > That problem is resolved using a different CMakeLists. I am having
>>> a
>>> >>> > slightly different problem now. The tool works now but when it is
>>> >>> > giving an
>>> >>> > error:
>>> >>> >
>>> >>> > #include <stddef.h> not found
>>> >>> >
>>> >>> > I checked the directories using -v and two directories namely
>>> >>> > "../lib/clang/3.2/include" and "/include" were not found. As you
>>> can
>>> >>> > see,
>>> >>> > these paths are wrong. They should be "/usr/local/lib/clang.." and
>>> >>> > "/usr/include". How can I fix this?
>>> >>> >
>>> >>> > The second problem is that I want to run this tool on a source file
>>> >>> > rather
>>> >>> > than code given through command line. How do I do that? I also
>>> want to
>>> >>> > retain the original locations in the source file so that I can
>>> rewrite
>>> >>> > to
>>> >>> > it.
>>> >>> >
>>> >>> > Regards.
>>> >>> > Adil
>>> >>> >
>>> >>> > On Fri, Oct 19, 2012 at 8:26 PM, David Blaikie <dblaikie at gmail.com
>>> >
>>> >>> > wrote:
>>> >>> >>
>>> >>> >> On Fri, Oct 19, 2012 at 3:52 AM, madil90 <madil90 at gmail.com>
>>> wrote:
>>> >>> >> > Hi,
>>> >>> >> >    I am trying to setup LibTooling for clang. I have gone
>>> through
>>> >>> >> > the
>>> >>> >> > procedure given at </a>
>>> >>> >> > <http://clang.llvm.org/docs/HowToSetupToolingForLLVM.html> . I
>>> can
>>> >>> >> > succesfully run clang-check for any source file. I am now
>>> trying to
>>> >>> >> > compile
>>> >>> >> > the example at  </a>
>>> >>> >> > <http://clang.llvm.org/docs/RAVFrontendAction.html>
>>> >>> >> > .
>>> >>> >> > When using cmake, I get the following error:
>>> >>> >> >
>>> >>> >> > Unknown CMake command : add_clang_executable
>>> >>> >> >
>>> >>> >> >   When using cmake to build clang, I used
>>> >>> >> > -DEXPORT_CMAKE_COMPILE_COMMANDS=ON
>>> >>> >> > variable as suggested. Then why isn't this command working?
>>> >>> >>
>>> >>> >> My best guess would be that you don't have a version of cmake that
>>> >>> >> supports this command, but I don't really know. This
>>> functionality was
>>> >>> >> only added (to both Clang an CMake) in the last 6 months or so.
>>> >>> >>
>>> >>> >> >
>>> >>> >> > Regards,
>>> >>> >> > Adil
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > --
>>> >>> >> > View this message in context:
>>> >>> >> >
>>> >>> >> >
>>> http://clang-developers.42468.n3.nabble.com/LibTooling-CMake-Error-tp4027570.html
>>> >>> >> > Sent from the Clang Developers mailing list archive at
>>> Nabble.com.
>>> >>> >> > _______________________________________________
>>> >>> >> > cfe-dev mailing list
>>> >>> >> > cfe-dev at cs.uiuc.edu
>>> >>> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > --
>>> >>> > Mohammad Adil
>>> >>> > LUMS SSE
>>> >>> >
>>> >>> >
>>> >>> > _______________________________________________
>>> >>> > cfe-dev mailing list
>>> >>> > cfe-dev at cs.uiuc.edu
>>> >>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> >>> >
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Mohammad Adil
>>> >> LUMS SSE
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> cfe-dev mailing list
>>> >> cfe-dev at cs.uiuc.edu
>>> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>> >>
>>> >
>>>
>>
>>
>
>
> --
> Mohammad Adil
> LUMS SSE
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20121021/4687c128/attachment.html>