[cfe-dev] Paths to system header files
Pedro Delgado Perez via cfe-dev
cfe-dev at lists.llvm.org
Fri Feb 26 08:14:10 PST 2016
Thank you Mikhail and Jacob,
> So, the two vectors are filled with the header's name and content, attachedis the method I use to embed them. It isn't an ideal solution but it works.I created a small script that (more or less) automatically converts all thebuiltin headers to strings. If you want it, just let me know.
Right now, I don't understand why I need to convert the builtin headers to strings, but of course I would like to have a look to the script. Any help is very welcomed. You can send it directly to me email if you prefer.
> After both vectors are filled, I simply do (bold):
clang::tooling::FixedCompilationDatabase Compilations("./",compiler_string);
std::vector<std::string> sources;
sources.push_back("/esbmc_intrinsics.h");
sources.push_back(path);
clang::tooling::ClangTool Tool(Compilations, sources);
Tool.mapVirtualFile("/esbmc_intrinsics.h", intrinsics);
for(auto it = clang_headers_name.begin(), it1 =clang_headers_content.begin();
(it != clang_headers_name.end()) && (it1 !=clang_headers_content.end());
++it, ++it1)
Tool.mapVirtualFile(*it, *it1);
Ok, I catch the idea, but I have some doubts:
- "esbmc_intrinsics.h" is always that string? is that a real file?
- What are "path", "instrinsics" and "compiler_string" in your code?
> As soon as clang 3.8 is released, we'll open source our project that usesthis code, so it'll be easier to understand how it's done. I hope thishelps for now.Also, You will need clang 3.8, as this doesn't work on clang 3.7.
Could you tell me then how to obtain clang 3.8?
Thanks again.
El día 26 feb 2016 14:06, Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es> escribió:
>
> Sorry about the format of the previous message. I write it again here.
>
>
> Sorry, Jacob, no idea on how to use your solution in my code. Manuel, nothing is written in your message I think...
> My code is something like this:
>
> static cl::OptionCategory MyToolCategory("My tool options");
>
> int main(int argc, const char **argv) {
> CommonOptionsParser OptionsParser(argc, argv, MyToolCategory);
> ClangTool Tool(OptionsParser.getCompilations(),
> OptionsParser.getSourcePathList());
> return Tool.run(newFrontendActionFactory<SyntaxOnlyAction>().get());
> }
>
> What I was doing by the moment is to process argv before creating the object OptionsParser and then include internal Clang headers, but I guess I can't do that when using Json compilation database. Could you help me with that? Otherwise, is there a way to ship in the executable all the necessary headers so that the user does not require to have clang installed?
>
>
> Thanks.
>
>
>
> El día 26 feb 2016 14:03, Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es> escribió:
>>
>> Sorry, Jacob, no idea on how to use your solution in my code. Manuel, nothing is written in your message I think...
>>
>> My code is something like this:
>> static cl::OptionCategory MyToolCategory("My tool options"); int main(int argc, const char **argv) {
>> CommonOptionsParser [ http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1CommonOptionsParser.html ] OptionsParser(argc, argv, MyToolCategory); ClangTool [ http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1ClangTool.html ] Tool(OptionsParser.getCompilations(), OptionsParser.getSourcePathList()); return Tool.run [ http://clang.llvm.org/doxygen/classclang_1_1tooling_1_1ClangTool.html#acec91f63b45ac7ee2d6c94cb9c10dab3 ](newFrontendActionFactory<SyntaxOnlyAction>().get()); }
>> What I was doing by the moment is to process argv before creating the object OptionsParser and then include internal Clang headers, but I guess I can't do that when using Json compilation database. Could you help me with that? Otherwise, is there a way to ship in the executable all the necessary headers so that the user does not require to have clang installed?
>>
>> Thanks.
>>
>>
>>
>> El día 26 feb 2016 10:37, Pedro Delgado Perez <pedro.delgadoperez at mail.uca.es> escribió:
>>>
>>> Hello,
>>>
>>> Perhaps this question has been asked before, but I couldn't find a proper solution for this issue. When I produce an executable and use it in another machine, sometimes Clang is not able to find system header files (for instance "limits.h") because the paths to find these headers are relative to the location of the Clang libraries.
>>>
>>> All the same, when I'm using FIXED COMPILATION, I'm able to automatically retrieve the paths to system headers of the machine where the executable is being run. I mean, I retrieve the paths and add them after "--" to the command through the option -isystem. However, when I'm using JSON COMPILATION DATABASE, I can't do that, so in this case I don't know how to solve this issue.
>>>
>>> What is the appropriate manner to handle this matter of the paths to system header files?
>>>
>>> Thanks.
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160226/96d73f5e/attachment.html>
More information about the cfe-dev
mailing list