dev-cafe / cmake-cookbook Goto Github PK
View Code? Open in Web Editor NEWCMake Cookbook recipes.
License: Other
CMake Cookbook recipes.
License: Other
Some of the failing builds, fail the whole CI. But maybe we want to show that some stuff doesn't work. How can we implement an "expected failure" behavior?
Taken from #2.
Currently we are actually not testing anything.
Write Fortran example, explain differences in CMake versions.
This is a very delicate procedure. One has to be aware of visibility issues and differences in between different compilers and operating systems. I think we should save it for a more advanced recipe
Good resources:
AppVeyor ships 3 images (see here):
We should use all three images, because:
However, I am not sure about MinGW vs. Cygwin. Should we try to use both? Or just one of the two?
This means that rerunning tests on local machines can mask errors.
This will be useful both for refactoring scripts as well as testing new recipes without rerunning the entire phalanx.
It would be nice to give statistics on CMake usage in the introduction. Datasets we can use:
This will show the name of the recipe and link to the directory.
Recipe 12 (Python library) and recipe 17 (Eigen) have been modified. TypeCloud should be updated.
Intel compilers, Intel MKL/ScaLAPACK, Intel MPI (probably)
There seems to be two options, which are currently shown in the C++ and C examples for recipe 16 in Chapter 3.
Use the MPI compiler wrapper. If I do VERBOSE=1 make
I see the compile line:
/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/bin/mpicxx
-std=c++11 -o CMakeFiles/hello-mpi.dir/hello-mpi.cpp.o
-c /home/roberto/Workspace/robertodr/cmake-recipes/Chapter03/recipe-0016/cxx-example/hello-mpi.cpp
and the link line:
/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/bin/mpicxx
CMakeFiles/hello-mpi.dir/hello-mpi.cpp.o -o hello-mpi -rdynamic
mpicxx --showme:compile
shows that the wrapper has added
-I/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/include -pthread
mpicxx --showme:link
shows that the wrapper has added
-pthread -Wl,-rpath -Wl,/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/lib -Wl,--enable-new-dtags -L/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/lib -lmpi_cxx -lmpi
Use the unwrapped compiler and then prepare the wrapper using CMake using target_compile_options
, target_include_directories
and target_link_libraries
. The compile line is:
/nix/store/j1yn1np5g2vgm5yp8qmqg67x8riwy2kr-gcc-wrapper-5.4.0/bin/gcc
-I/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/include
-std=c11 -o CMakeFiles/hello-mpi.dir/hello-mpi.c.o
-c /home/roberto/Workspace/robertodr/cmake-recipes/Chapter03/recipe-0016/c-example/hello-mpi.c
and the link line is:
/nix/store/j1yn1np5g2vgm5yp8qmqg67x8riwy2kr-gcc-wrapper-5.4.0/bin/gcc
CMakeFiles/hello-mpi.dir/hello-mpi.c.o -o hello-mpi -rdynamic -lmpi
Whereas the wrapper tells me:
-I/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/include -pthread
for the compile line and
-pthread -Wl,-rpath -Wl,/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/lib -Wl,--enable-new-dtags -L/nix/store/8f1nmsd4cw7sdk8xrssmkk9zbq26pc2j-openmpi-1.10.1/lib -lmpi
for the link line
This is the same for C and C++ (and most likely for Fortran too) You can see that some of the wrapper options have disappeared, both for compiling and linking. What is the best practice here? Reset the compiler to the wrapped version discovered by CMake?
My take on menu.yml
:
appveyor:
env:
definitions:
expect_failure:
- true
- fail_message: 'Build does not work in this case'
drone:
env:
definitions:
- CMAKE_CXX_COMPILER: g++
travis:
env:
definitions:
- CMAKE_CXX_COMPILER: g++
Three mandatory sections, with fixed names, one for each CI service we are using.
Each section has env
and definitions
subsections. The end goal is to avoid logical switches in the top-level script (like the one we have now for Visual Studio and Fortran)
Use recipe names instead of numbers
This will give us a complete draft of Chapter 3 without offsetting deadlines:
pkg-config
in recipe-0020FindOpenACC.cmake
either beef up recipe-0020 or add a recipe-0021This will have to be tested on the Drone instance. Here's an example online: https://github.com/pnkelly/GPULife/blob/master/testing/cmake/Modules/FindOpenACC.cmake
The CI script is very simple-minded. Things to improve:
STATUS
messages from CMake are printed elsewhere from where you'd expect (separate from the CMake configuration output stream) I suspect CMake might use the stderr instead of stdout for these.direnv
to no avail. Maybe I can get you up to speed with what I've done, before we decide the next steps.See https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/.
Many recipes currently fail because of unmet dependencies:
Set up Drone CI using this instance: https://www.drone-ci.science/
These two recipes cover:
Use milestones and assignees. Also, recipes should become issues.
Should we perhaps number recipes only within chapters? For book readers they will be easy to find since they can search by chapter. For instance chapter-9/recipe-4
would be 4th recipe in chapter 9. This would spare us the work and possible breakage of renumbering recipes. Especially if we draft recipes across chapters and not chapter by chapter.
Roberto, can you please have a go at this since you know best what you meant when writing these down. It would IMO be good to track them in one place (issue tracker).
Builds on Travis CI for Mac OS X are currently failing. Two problems:
menu.yml
for this.uuid_generate_time_safe
is not there. I'll fix it by using uuid_generate
in the source code.See here: cmake-recipes/Chapter03/recipe-0013/FindPythonModule.cmake
Works:
find_package(PythonModule COMPONENTS numpy REQUIRED)
Works:
find_package(PyhonModule COMPONENTS numpy matplotlib REQUIRED)
Works:
find_package(PythonModule 1.12 EXACT COMPONENTS numpy REQUIRED)
Ambiguous:
find_package(PythonModule 1.12 EXACT COMPONENTS numpy matplotlib REQUIRED)
Requires #34 to be merged.
CMAKE_<LANG>_FLAGS_<CONFIG>
. See herelink_directories
, include_directories
, add_compile_options
, link_libraries
Not really this repo related but just to have overview of who is doing what.
I've numbered them in ascending order from chapter 1.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.