How can I bypass dependency builds while building my clang plugin? - c++

Is it possible to build a clang plugin using an already built version of clang?
I've done all the steps to download and build clang but I don't know how to set up a tool so that the Makefile doesn't traverse the entire llvm and clang directories each time that I compile my tool (traversing the Makefile seems to take about as long as building my single file plugin).
Thanks.

If you are using the CMake build system (which you should be with reset LLVM), then CMake creates special targets to bypass dependency checks.
If you target name is target, call:
make target/fast
And then the Makefile will not check/rebuild all the dependent libraries. There is also a make install/fast.

Related

Custom build cmake using standard library also for project with lower gcc version

I have a custom build cmake v3.10.0 which was compiled with a gcc_4.8.3. I am using this custom build cmake to compile a cmake project that must use gcc _4.1.2 because of legacy code.
Executing cmake promted me with an error because it needs to use the libstdc++-IFX.so.6 provided by gcc_4.8.3 which I fixed by adding the path to the correct library in my LD_LIBRARY_PATH before the path to the libraries provided by gcc_4.1.2.
Compiling my project and linking an executable (which is done by c++) results in the linker taking the gcc_4.8.3 stdlibs over the gcc_4.1.2 libs. Is there any way to tell cmake to not use the libraries it needs for himself for my cmake project preferably without touching LD_LIBRARY_PATH?
Edits:
#squareskittles comment: I did read and try everything this post suggest but without any changes. The libstdc++-IFX.so.6 is still taken from gcc_4.8.3

How to add a X86 backend pass in LLVM without having to rebuild all sorts of shared libraries, including clang?

How to add a X86 backend pass in LLVM without having to rebuild all sorts of shared libraries, including clang?
After having studied the LLVM "middle-end" for a while (IR/opt), I've decided to move into the backend.
Here, I've created a very simply MachineFunctionPass in .../lib/Target/X86/, which compiles just fine.
Now, from what I understand, I cannot just load the LLVM backend pass using llc, like it was possible for opt w.r.t. IR-passes. Instead, I've have to build the new pass into the LLVM infrastructure, so I issue the command cmake . --build from my llvm/build directory.
This has the effect that all sorts of shared libraries are build again, including all kinds of clang specific .so files.
The problem is that this take more than 30 minutes, so this cannot be the correct way of building a simple backend pass. How do I quickly configure and build the pass into LLVM, so that I can use it with llc?
I am not an expert in LLVM, but this seems to work for me:
Go the LLVM build directory: cd ~/llvm/build/.
Proceed to the llc build directory: cd tools/llc/.
Build llc: cmake --build.
Now, instead of using the topmost cmake build script, which causes the entire project to be build (changed files and dependencies), only the llc tool is build.
I haven't tested this thoroughly.
Slightly different from the above post:
cmake -G Ninja ...
to configure llvm.
Then
ninja llc
should work fine.

CMake doesn't compile OpenCV

AFAIK, CMake is a tool for automated builds, so what I would expect from CMake is to "Make" the whole thing, i.e., when I hit "generate" it will create all the files, and compile them, so I will have all I need.
But instead when I run CMake on OpenCV it makes a VS2010 Solution and lots of projects, and then I have to open it in VS2010, and compile the projects myself...why CMake doesn't do it all in a single operation? I think it's capable of doing so right? So why not?
EDIT:
In this link they show how this is the regular way.
Take a look at CMake page:
"CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice."
On the OpenCV website you can find a complete guide to the installation on your Windows machine

Creating a clang tool that can run on existing makefile projects in a Windows Evironment?

I want to write a clang tool that can run on C++ projects that I have that already exist which use Makefiles to build. The problem is, it seems as though any project that is going to be put through a clang AST must be built using cmake so that it can get a compile_commands.json file. Is there a way to do this for projects that don't use cmake? Or is there a way to build Makefile projects with cmake?
You might be able to use this script with cygwin:
https://github.com/woboq/woboq_codebrowser/blob/master/scripts/fake_compiler.sh

Bullet Physics, CMake->CodeBlocks - MinGW: Doesn't find GL/glut.h?

Statistics...
My System: Windows Vista 64 bit
Library: Bullet Physics v2.78
Makefile Generator: CMake
Build system: MinGW command line, MinGW + CodeBlocks
Makefiles were implemented by command line and through CMake-generated Code::Blocks project
In both cases, the build fails near 30%. NOTE: I did have to switch the build executable in the Code::Blocks project from make.exe to mingw32-make.exe
First Failure: Demos\OpenGL\GLDebugFont.cpp -> GL/glut.h: No such file or directory
Second Failure (after commenting out the #include from the first) -> Demos/OpenGL/GlutStuff.h: same error
These failures happen when I build command-line OR through the generated C::B project.
Why can't it find GL/glut.h? "bullet-2.78\Glut\GL\glut.h" exists. Maybe there's a way I can tell it to find glut there?
NOTE: During the CMake makefile generation, CMake did tell me that "You are using the obsolete GLU package, please use OpenGL instead." It continued as normal with the Makefile generation. Maybe I need to define some environment variables? Maybe I need to configure something in Windows that CMake is looking for?
I would add a compiler search path in bullet-2.78/Glut, but Code::Blocks doesn't allow that if you're using a custom makefile (like a CMake-generated one).
UPDATE: I have been able to build the library itself, by building specific targets in the Code::Blocks project. However, I have been unable to build any of the demos or the benchmark test, since they all use OpenGL (and apparently glut.h). I would still like to compile those.