It would be nice to give statistics on CMake usage in the introduction. Datasets we can use:

• Stackoverflow datasets: https://www.kaggle.com/stackoverflow/datasets
  I think the want we want to sample for statistics is this one: https://www.kaggle.com/stackoverflow/stacklite
• Google trends

Recipe 12 (Python library) and recipe 17 (Eigen) have been modified. TypeCloud should be updated.

There seems to be two options, which are currently shown in the C++ and C examples for recipe 16 in Chapter 3.

C++ Example

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

C Example

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

Question

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?

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.

These two recipes cover:

• Setting compiler flags
• Setting the standard for the language

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:

• http://gernotklingler.com/blog/creating-using-shared-libraries-different-compilers-different-operating-systems/
• https://cmake.org/cmake/help/v3.3/module/GenerateExportHeader.html?highlight=generate%20export

The CI script is very simple-minded. Things to improve:

1. The report dumps all info to screen. Should we agree on a less cluttered output format? EDIT I have also noticed that non-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.
2. 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?
3. It would be good to move the environment variables inside the various subdirectories. I think this will contribute to have cleaner build matrices on the CI services. I have played around with direnv to no avail. Maybe I can get you up to speed with what I've done, before we decide the next steps.

Requires #34 to be merged.

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)

Builds on Travis CI for Mac OS X are currently failing. Two problems:

• Apple Clang does not support OpenMP. Some recipes in chapter 3 require OpenMP. We need the expected failure section in menu.yml for this.
• The implementation of UUID seems not to be the same as on Linux, specifically the uuid_generate_time_safe is not there. I'll fix it by using uuid_generate in the source code.

See https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/.

• Document in book
• Motivate in book
• Update recipe sources on GitHub side
• Update source snippets that mention 3.0 in the book

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)

Set up Drone CI using this instance: https://www.drone-ci.science/

Intel compilers, Intel MKL/ScaLAPACK, Intel MPI (probably)

Write Fortran example, explain differences in CMake versions.

Use recipe names instead of numbers

Not really this repo related but just to have overview of who is doing what.

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.

• Use targets and properties
• Do not use CMAKE_<LANG>_FLAGS_<CONFIG>. See here
• Do not use link_directories, include_directories, add_compile_options, link_libraries
• Present the analogy between C++ objects and CMake targets.
• This presentation by Daniel Pfeifer sums up all these things very neatly. Slides on GitHub

Currently we are actually not testing anything.

This will show the name of the recipe and link to the directory.

Use milestones and assignees. Also, recipes should become issues.

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.

This 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

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).

This will give us a complete draft of Chapter 3 without offsetting deadlines:

• Remove recipe-0017 (OpenACC parallel environment)
• Show how to find LibUUID with pkg-config in recipe-0020
• Move recipe-0021 to a later chapter (to be discussed)
• When we have FindOpenACC.cmake either beef up recipe-0020 or add a recipe-0021

AppVeyor ships 3 images (see here):

• VS 2013. MinGW and Cygwin pre-installed
• VS 2015. MinGW and Cygwin pre-installed
• VS 2017. Only Cygwin pre-installed

We should use all three images, because:

• CMake 3.0 supports VS 2013, at most.
• CMake 3.9 supports all three of them.

However, I am not sure about MinGW vs. Cygwin. Should we try to use both? Or just one of the two?

Many recipes currently fail because of unmet dependencies:

• Boost
• Eigen
• HDF5
• MPI
• BLAS
• LAPACK

I've numbered them in ascending order from chapter 1.

This will need the Drone instance for testing.

Requirements

• If C/CXX are enabled, it should also find headers for CBLAS and LAPACKE
• Possible example here for BLAS.
• Possible example here for LAPACK.