I'm using cmake to build my project, and I want it to integrate with a third party library called Project_A that using autoconf to generate make, how to write the CMakeLists.txt to build the Project_A and my project together?
Thanks!
I think using the ExternalProject module in CMake would be the best solution. See here for a good introduction to the api.
If you are wanting to do lexical code reuse (ie, copy-n-paste the code rather then relying on a dependency), then don't stop half way. By using the external code in this way, you are essentially claiming ownership of it for the purpose of your project, so there is no need to keep the autotool build. Just pull the code out and build it via cmake. Don't bother trying to create a hybrid build.
Related
I see some make files in this repository which makes me wonder if Make can build itself by using make files or it needs to be installed first via some other mechanism? I am a beginner at this so this question is educational.
Can Make build itself by using its own functionality
There are many implementations of Make.
GNU Make can be compiled with shell and compiler. GNU Make can also invoke compiler with Make.
if Make can build itself by using make files
Yes, it "can".
it needs to be installed first via some other mechanism?
No.
This all is unrelated to CMake. Make and CMake are separate programs. In general, it's way more fragmented.
I have two separate git repositories that I am not sure how to best bring together using cmake. I would like a solution that is cross platform.
I have a C++ library project which produces a static library (and C++ headers). This project has its own cmake which will produce a static library. I haven't yet written an install step in the cmake.
I have a UI (Qt) project which visualizes the product of this library. This also is based on cmake and should be using the library; in fact, it does not make sense without the library.
What is the best practice for a situation such as this? I could imagine a few things:
The library is a git submodule of the UI project and the cmake of the UI uses add_subdirectory()
The UI build expects the user to have built and installed (to the system) the static library & headers
The UI build has a hard coded path (or ENV var) to the cmake of the library (or something like LibraryConfig.cmake, but I'm not familiar enough with this yet)
My end goal is that the user should be able to pull, build, and use the library in their own projects, but if in the future they feel necessary, they can grab the visualization tool additionally and use it with the library. Also, people who are not comfortable with using the library themselves might just want to clone the visualization tool repo and build & use it.
I wrote a piece of software which works well on my own box. It has been a headache to get it onto another box, though.
The main problem is that there is a library which it uses which is not a library covered by apt-get; it's called pngwriter. And pngwriter is also very finicky, and it is not very easily installed. It also has version compatibility issues. To get around all of that, I thought it would be great to include the source for pngwriter with my project, and have CMake go ahead and make pngwriter with the rest of the code.
So my main question is: Is this type of deployment canon? Should CMake call the makefiles that the developers of the software already wrote, and then use FIND_PACKAGE locally, or will I need to rewrite all of their makefiles so that I can use ADD_LIBRARY?
I'd recommend using the ExternalProject_Add function.
The docs are OK, but there is a decent article which explains things in a bit more detail. From this article:
The ExternalProject_Add function makes it possible to say “download this project from the internet, run its configure step, build it and install it”
Bear in mind that you can skip the install step altogether, or you could choose to install to a location inside your own build directory.
What I am looking for:
Download library
Extract It
Apply custom patch
Run configure
Run build command
What library I am trying to build are:
Openssl
Boost
Thrift
C-ares
Curl
Pcre
Nginx
ICU
JsonCPP
I think I can do these things using external module: http://cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject
But I have following question?
I have different type of build and with different directory. Is it
going to build all these library for every different target? If yes
it will be painful as all these library take one hour to build. Is
there a way I can control it and it only build it once. As library
remains same for all these targets.
On switching directory to different name. Cmake force everything to
be rebuild-ed. Will it be same for external library. If yes? How to
solve this problem. I don't want to rebuild the library if I am not
changing them and want to use them while switching to different
branches without building them.
Yes, you can use CMake's ExternalProject feature to accomplish what you want to do.
When using cross-compilation in combination with external projects, the source code will be built once for each toolchain. You could avoid rebuilds if you checked in the results of the build into a source-control system, and re-checked it out on each new person's machine, but I do not recommend this. Instead, have one of your "set up new computer" tasks actually be allowing the compilation to run overnight, which will also act as a test that the machine is actually usable. That set-up task can be launched by a system administrator prior to a new hire's arrival, or you can leave it to the new hire, as circumstances require.
I'm not completely certain what you are asking in your second question, but if the library is unchanged, CMake will detect that it is unchanged and not recompile it. Typically, the source code would be in a single directory tree: each compiled version would be built in a distinct location. Thus, developers can access any compiled version at any time just by switching directories. This is particularly helpful because it allows you to mount these directories over NFS to embedded hardware, et cetera.
I'm currently investigating cmake to allow automatic building on the Win32 platform. For all runtimes and libraries I'd like to build, Visual Studio (2008/2010) projects do allready exist.
I've come across cmake, but I'm unsure if I really need it. As the documentation says, cmake generates VS projects and they then can be built e.g. using MSBuild.
As the projects itself allready do exist (and build nicely via the IDE or MSBuild on the cmd line), what do I need and use cmake for? Just for directory/project folder traversal? Build failure reporting?
Regards,
Paul
Well, strictly speaking you do not need it. However, it does give you a few advantages:
The idiomatic way to use CMake, forces you to use out-of-source builds. Arguable, but I am personally convinced that these keep you source-repository very clean.
You can support multiple visual studio versions (with the out-of-source builds). Perhaps it will be a little easier to port your project to other compilers (from MinGW -> Linux GCC).
With the find_package and config.cmake files, and a large number of available findXXX modules, CMake makes it a lot easier to "import" third-party libraries into your build-chain.
You don't need it. Cmake is only useful if you are trying to keep the same source code able to build in multiple platforms and compilers. If you are simply building using the microsoft stack you have no need of it.