Following the answeres to how to use multiple inline assertions in Frege I learned how to compile two Frege modules A and B where B depends on A: you have to compile B. If given the -make option, the compiler will figure out that B depends on A, will find A on the sourcepath (-sp flag), and will compile A first and then B.
However, I cannot just give all files I care about to the compiler. Giving both A and B to the compiler failed with a "cyclic dependency" error for me. And I also found no way to give a directory to the compiler (it just did nothing).
This looks like I had to know the root of the dependency graph to do a proper compilation of all need-to-be-compiled files. But
I may not know the root.
There may be many of them.
It's very difficult to do a proper build automation that way.
Is there a combination of compiler options where I can just let the compiler compile all files in a source tree?
This issue has now been addressed by the frege-maven-plugin:
https://github.com/Frege/frege-maven-plugin
which is available in maven central.
EDIT: With more recent compiler releases, you can indeed compile whole trees:
java -jar fregec.jar -d classes/ -make directory1/ directory2/
Insofar, the answer below is obsolete.
The short answer is "no".
The long answer:
If you have an application, you should know the roots, it's the modules that contain main functions. One can compile all of them at once with the -make option, as long as they do not depend on each other.
In case of libraries, you could create a pseudo module that just imports all modules that belong to the library and compile that one.
If none of the above helps, and you simply need to compile "all that is there", you can do so by just passing all file names with the -make option (see below). The downside is that some files may get compiled twice.
The Frege builder of the eclipse plugin does compile all files in the correct order on a full build.
It would seem that such functionality is needed also for the command line compiler.
By the way, I couldn't retrace your "cyclic dependency" error. I used the following command:
java -jar ~/frege/fregec.jar -d bin -make -sp Real_World_Frege-master/ $(find . -type f -name '*.fr' -print)
In fact, this error should only be flagged in the case that A imports B while B (or something that B imports) imports A.
Related
I have some legacy code (building against the mysql embedded server library) which contains a link line that looks like this:
-L/usr/local/lib -lmysqld -lm -ldl -lcrypt -lpthread
I know that I can get a list of supported cmake modules with cmake --help-module-list, but how do know which modules contains the libraries libm.a, libdl.a, etc.?
I know that I could use link_directories(/usr/local/lib) to specify that location, and just put -lm, -ldl, etc. into my target_link_libraries command, but the docs seem to discourage that - that using find_library or find_package is desirable.
I can probably muddle through putting together something with find_library that will work with all our target platforms, but if these libraries are already defined in an existing package, I think that would be the most desirable way to do it.
So, the general question is: given some known libraries, how to I locate the relevant cmake package that contains them?
EDIT: There seems to be some confusion about what I'm asking. I understand that find_package doesn't actually "contain" the libraries, but it serves as platform-independent way of locating the libraries for common configurations. For example, in my case above, I found in another SO question that I could deal with the pthread library by using this construction:
set(THREADS_PREFER_PTHREAD_FLAG ON)
find_package(Threads REQUIRED)
target_link_libraries(my_app Threads::Threads)
But how was I supposed to know this? Is there a way I can discover this for myself without asking SO questions and hoping someone can answer it for me? And what should I use for the other libraries (m, dl, crypt, etc.).
given some known libraries, how to I locate the relevant cmake package that contains them?
If corresponded CMake package exists, it usually has a name similar to the name of the library.
Note, that CMake package is not a container for a library (like distro packages are, e.g. mysql-devel). CMake package is simply a script, which finds a library.
Absence of the script doesn't mean absence of the library itself; it means .. that no one has writen such script. Nothing more.
I am trying to compile gtest from source (instead of using the existing installed version). I am working on a catkin based cmake project.
I have added the sourcecode from https://github.com/google/googletest to my workspace and included the folder with add_subdirectory.
However, I get a nameclash with the existing gtest:
CMake Error at src/test_env/GTest/googletest/cmake/internal_utils.cmake:151 (add_library):
add_library cannot create target "gtest" because another target with the
same name already exists. The existing target is a shared library created
in source directory "/usr/src/gtest". See documentation for policy CMP0002
for more details.
From other posts, and the googletest instructions itself (https://github.com/google/googletest/tree/master/googletest#incorporating-into-an-existing-cmake-project) I understand that this should be no problem.
I think the problem might lie in how catkin handles gtest. And, admittedly, normally I could just use the installed version. But I want to make sure, that everyone uses the same (bundled) version of gtest.
Any suggestions and hints are welcomed.
Okay, so the error message is actually quite clear. A cmake "target" is "something that will be produced by the build", be it a library, or an executable, or something else. So, the problem is that you are trying to add a target named "gtest", and catkin already does the same thing. Both would produce the library "libgtest.so", and of course there can only be one of those in the same folder. You could rename "your" gtest by changing the target name in googletest/CMakelists.txt, but I would strongly advise you to not do that.
In my opinion, gtest shouldn't even be a shared library at all, especially if you are using different build flags for different projects in your repository. There is an alternative, and that is basically only including the gtest source code in a folder, and then including the header files and source files in your unittests main.cpp. googletest already comes with helpers for that, that is src/gtest-main.cc.
This is how I would structure it:
Add the gtest version you want as submodule to git (in case you use git). This way, you have a specified version for all projects in your repo, and can update it in a different branch. I will call that folder "GTEST_DIR".
Write your unittests in .cpp files, that #include <gtest/gtest.h>, one per hpp you want to test, and #include both the hpp and the cpp in your test.cpp. This enforces the separation of your tests from other classes and makes it very easy to switch out dependent classes with mocks or fake objects. You will not need a main() function, as that one is already in gtest-main.cc.
Write a cmake macro like this:
macro(add_gtest NAME FILES)
add_executable(my_gtest_$NAME
$FILES
GTEST_DIR/src/gtest.cc
GTEST_DIR/src/gtest-death-test.cc
GTEST_DIR/src/gtest-filepath.cc
GTEST_DIR/src/gtest-port.cc
GTEST_DIR/src/gtest-printers.cc
GTEST_DIR/src/gtest-test-part.cc
GTEST_DIR/src/gtest-typed-test.cc
GTEST_DIR/src/gtest-main.cc
)
target_include_directories(my_gtest_$NAME GTEST_DIR/include)
endmacro()
Of course, you can make this more complicated or less complicated, but that is the gist. Of course, compile times will be longer this way over using gtest as a shared library, but it actually makes sure your units get tested in isolation, which is very valueable in my opinion. Also, you can use ccache to greatly improve compile times in this scenario, because the gtest object files never change. Also, this will make sure gtest is compiled with exactly the flags you want it to. You could for example create 2 separate unit tests for the same class, one with exceptions enabled and one without.
I was trying to parallelize a Fortran program using MPI. I use CMake to do the build of my program. It was difficult to find support on getting CMake to create a working makefile for Fortran with MPI support on google, but from what I could gather, I added the following commands to my CMakeLists.txt script:
find_package(MPI REQUIRED)
add_definitions(${MPI_Fortran_COMPILE_FLAGS})
include_directories(${MPI_Fortran_INCLUDE_DIRS})
link_directories(${MPI_FortranLIBRARY_DIRS})
This will locate MPI on my system and then set the variables found in the following three commands. In my linking line, I added the MPI libraries variable to the list of the other libraries that my program needed to build.
target_link_libraries(${exe_name} otherlibs ${MPI_FortranLIBRARY_DIRS})
Doing cmake and then make worked to build the program and the program ran; however, when I tried to add more to the source which required me to include the mpif.h include file, my compilation failed due to not being able to find this header file. I also could not use mpi because the compiler cannot find the mpi.mod file in the path.
I inserted "message" commands into my CMakeLists.txt file and printed out the values of the variables that I was using for including and linking. It turns out that the variables, MPI_Fortran_INCLUDE_DIRS and MPI_FortranLIBRARY_DIRS weren't set to anything. A check of the module that CMake is actually using to set these variables (FindMPI.cmake) showed these variables to be non-existent. I changed my CMakeLists.txt file to use the correct variables:
find_package(MPI REQUIRED)
add_definitions(${MPI_Fortran_COMPILE_FLAGS})
include_directories(${MPI_Fortran_INCLUDE_PATH})
link_directories(${MPI_Fortran_LIBRARIES})
target_link_libraries(${exe_name} otherlibs ${MPI_Fortran_LIBRARIES})
Now when I execute make, the compiler could find both mpif.h as well as mpi.mod.
UPDATE:
I want to mention that this solution worked for cmake version 2.8.10.1. When I moved my CMakeLists.txt scripts to a different machine that has cmake version 2.8.4, I get the same error about mpi.mod missing during the link stage. I checked the FindMPI.cmake module and, sure enough, there are no variables that specify the language (i.e. there is no MPI_Fortran_LIBRARIES variable, just a MPI_LIBRARIES variable, and this variable is not getting set to the correct location of the mpi library on that system. So this solution will be dependent on cmake version.
Sounds like you are not using the mpi compiler. That is fine, but you have to add a lot of flags then. There is not really an mpi compiler but a wrapper that sets the flags to be able to use mpi. With cmake I was able to do this by defining the fortran compiler I was going to use BEFORE the call to cmake. It's not a nice solution since you loose portability, but it works. I'm trying to find a better solution and define inside cmake what compiler to use, but have not been able to do so. In other words, this works for me:
FC=mpif90 cmake ../.
make
I was having the same problem as you. Hope this solves the issue. If anybody finds how to define the fortran compiler INSIDE cmake please post it!
as you've already noticed, you misspelled the name of two variables, namely MPI_Fortran_LIBRARIES and MPI_Fortran_LIBRARIES
It is useful also to add:
cmake_minimum_required(VERSION 2.8.10)
at the very beginning of your CMake to be sure that these variables will be defined.
CMake is awesome, especially with lots of modules (FindOOXX). However, when it comes to write a FindXXX module, a library XXX which your project depends, it's not that easy to handle for non-cmake-expert. I sometimes encounter a library without support to CMake, and I like to make one for it. I'm wondering if there is any interactive shell while writing/testing cmake modules?
Are you writing FindXXX for project "XXX" or is "XXX" a dependency of your project that you're trying to find? If the former, you should instead write a file called XXX-config.cmake (or XXXConfig.cmake) and install it into one of the directories mentioned in the docs for find_package. In general, XXX-config.cmake files are for projects which are expected to be found by CMake (and installed by the project itself) and FindXXX.cmake files are for projects which don't support CMake (and usually have to support finding any version of XXX).
That said, for FindXXX.cmake, usually you just need a few find_file (e.g., for headers), some find_library calls, or even just a single pkg_check_module from FindPkgConfig.cmake followed by a find_package_handle_standard_args call (use include(FindPackageHandleStandardArgs) to get it). FPHSA makes writing proper Find modules a breeze.
For XXX-config.cmake files, I have typically used configure_file to generate two versions: one for the install (which includes your install(EXPORT) file) and one for the build tree (generated by export() calls). Using this, other useful variables can be accurately set such as things like "which exact version of Boost was used" or "was Python support compiled in" so that dependent projects can get a better picture of what the dependency looks like.
I have also recently discovered that CMake ships with the CMakePackageConfigHelpers module which is supposed to help with making these files. There looks to be quite a bit of documentation for it.
I tried to search the CMake documentation, but I couldn't figure out how to call external programs from CMake.
There are few things I want to do.
Compile other third-party dependencies that uses a makefile
Compile Thrift definition files to C++ / Python stubs.
Compile Cython definition files.
Another question is, what is a good way to handle those cases anyway? It feels like calling a shell script directly from CMake doesn't feel so clean, when "C" in CMake stands for Cross Platform.
EDIT: I have few extra questions. Before, in my build, I prebuilt my dependencies, and the project itself used FIND_PACKAGE(...) to find the header / libraries for the dependencies.
Now, I'm ExternalProject_Add() to compile the dependencies, but the problem is, all my FindXYZ() functions fails when I run cmake ., because the dependencies aren't present when CMake gets executed.
How should I include the third-party libraries in my project in this case?
http://www.kitware.com/media/html/BuildingExternalProjectsWithCMake2.8.html
2+3. can be hacked with CONFIGURE_COMMAND/BUILD_COMMAND/INSTALL_COMMAND