I`m trying to find best solution for parsing C++ code for my refactor support tool. I decided to use clang frontend because it is meant to be frontend of C++ compiler. I found the documentation page that describes parsing of C++ code using clang LibTooling. But, unfortunately, it looks for me that LibTooling cannot be used separately from clang infrastructure installed on the tool user side.
So, my question: is it possible to compile Clang LibTooling to standalone parser that my be reused between C++ parse projects without clang infrastructure? Ideal solution for me is shown on the picture. I want to compile LibTooling linking it with my wrapping library (that may simplify / adopt LibTooling API for my purposes) and then reuse it between different projects.
P.S.: Maybe, something like it where performed in Firolino's clang project - but it looks that full clang installation should be used for too.
P.P.S.: As for me, solution that is whanted for my may be useful for all C++ community. So if somebody want to cooperate with me in making this project - you are welcome!
Related
I'm new to c++ compiling, tooling, llvm and such. I'm exploring ways of compiling some c++ apps for the browser. I'm not looking for solutions that just run the c++ app. For those situation emscripten seems to be just right. I'm looking for ways to build a hybrid app that has a lot of touch-points between the javascript part and the c++ part.
I had success compiling and running some c/c++ apps using the wasi-sdk provided clang and llvm. But the llvm provided by wasi-sdk does not support threads.
The wasi-sdk offers a set of stdlib that respect the wasi specification. This specification does not support multi-threading. Is there a way to add the pthreads from other stdlib implementations and implement the javascript glue code by hand (maybe seeking inspiration from emscripten). If yes, what would be the steps? LLVM seems to be compiled without threads support in wasi-sdk, so simply adding additional headers that define pthreads might not work.
Wasi (and wasi-sdk and wasi-libc) doesn't currently support threads. There is an effort underway to add support here: https://github.com/WebAssembly/wasi-threads
There have been several recent patches to wasi-libc: e.g. https://github.com/WebAssembly/wasi-libc/pull/325.
I have an existing and working source-to-source code modification tool using libtooling (written in C++). Now I want to integrate this tool into clang, so users can compile the modified source code without actually saving it somewhere.
The modification part isn't problematic, Matchers + Rewriters work the same way with clang, my problem is how to tell the compiler to reparse the source code after my changes.
I have a software that is able to generate C code that I would like to use in a just-in-time compilation context. From what I understand, LLVM/Clang is the way to go and, for maintainability of the project, I'd like to use the C API of llvm and Clang (libclang).
I started out creating a libclang context using clang_createIndex and a translation unit using createTranslationUnitFromSourceFile (would have been nice to be able to avoid going via the file system and pass the source code as a string instead). But I pretty much get stuck there. How can I go from the libclang translation unit to an LLVM "execution engine" which is what appears to be needed for JIT? Or is this not even possible using the C API?
The best method to learn how to use a body of code is to investigate the examples you're given.
There exist tutorials on how to leverage the clang/llvm tools to compile C++ code and emit LLVM-IR, to compile LLVM-IR to LLVM-Bitcode, and to execute that LLVM-bitcode. All that is necessary to learn to incorporate this functionality in our application is to investigate the execution path of these tools, to find the sequence of methods that accomplish what we want.
Here is an example using the example tools of compiling a cpp file to llvm-bitcode, and executing it.
clang++ -c -O3 -emit-llvm main.cpp -o main.bc
lli main.bc
This is a great start, we can just look at the source behind the tools, and investigate the execution path outlined by the arguments. Since these tools are merely interfaces exposing the underlying functionality available in the llvm/clang libraries that we can add to our project, following the execution path shallowly will give us a sequence of library available methods that we can call within our application to accomplish the same results.
Once the sequence of library methods is trivially established, you can delve into breaking individual library methods into their underlying functionality, and tease out the exact behavior we desire through a relatively small set of modifications here and there, rather than trying to reimplement something from the ground up.
We have a C++ template library that has some features that depend on zlib, for example.
We selectively enable and disable features using preprocessor symbols, i.e. setting -DHAVE_ZLIB=1 on the command line.
Our CMake-based build system recognizes installed zlib and adds the according flag to the compiler.
Of course, this can also be done manually by users, using their favourite IDE or their Makefiles.
One property of the library is that the code that uses zlib is interleaved with the code not using zlib, i.e. using #include <library/header.h> should work regardless of zlib being present or not.
Currently, we #if out code that depends on zlib.
Thus, if the user tries to use something like CompressedStream, for example, the class is simply not found.
This is quite frustrating for users.
The build system warns them that zlib could not be found, but users being users either do not see this or forget it quickly.
I myself have fallen into this trap, too.
Now to my question:
What is the best way to warn the user that zlib is disable if he tries to use code requiring zlib.
The only thing I can think of is using the deprecator marker mechanisms implemented in many compilers.
Although different syntax is required for each of them, this could easily be abstracted away using preprocessor macros.
Is there any other good way?
The solution only has to work in VS >8, GCC >4.2 and LLVM.
The proper place to warn users about such things is (IMO) build system. Take a look at Ogre3D, KDE and many other projects - all of them print sort of outline after configuration of build. This outline contains information on what is found and what is not and what are consequences of this.
Even Qt don't do anyting to fix this. There is option to build Qt with STL support and if it's not built such way, there are no warnings or whatever, only compile errors regarding undefined methods. So, i think, there is no way to warn user about such things during compile phase.
I need to compile code someone gave me, which they wrote in code::blocks. I know code::blocks uses gcc, but what is the specific format for the command(s) it uses to do so? Because of various circumstances, I can't use code::blocks myself for this, and I'm too rusty at compiling C/C++ to figure it out from the code.
check out this - cbp2make - makefile generation tool
haven't used it, just assumed it should exist
i imagine code blocks has a place for compilation and linking options, so i guess you could ask him what they are
The easiest way is to insert a small stub named gcc that records all its arguments and then forwards to the real GCC. This is fairly easy with a shell script.