How to generate CMakeLists.txt?

Question

I need some pointers/advice on how to automatically generate CMakeLists.txt files for CMake. Does anyone know of any existing generators? I\'ve checked the ones listed in the CM

Answer 1

I am of the opinion that you need not use an automated script for generating CMakeLists.Txt as it is a very simple task to write one, after you have understood the basic procedure. Yeah I do agree that understanding the procedure to write one as given in CMake Wiki is also difficult as it is too much detailed.

A very basic example showing how to write CMakeLists.txt is shown here, which I think will be of use to everyone, even someone who is going to write CMakeLists.txt for the first time.

Answer 2

I'm maintaining a C++ software environment that has more than 1000 modules (shared, static libraries, programs) and uses more than 20 third parties (boost, openCV, Qt, Qwt...). This software environment hosts many programs (~50), each one picking up some libraries, programs and third parties. I use CMake to generate the makefiles and that's really great.

However, if you write your CMakeLists.txt as it is recommended to do (declare the module as being a library/program, importing source files, adding dependencies...). I agree with celavek: maintaining those CMakeLists.txt files is a real pain:

• When you add a new file to a module, you need to update its CMakeLists.txt
• When you upgrade a third party, you need to update the CMakeLists.txt of all modules using it
• When you add a new dependency (library A now needs library B), you may need to update the CMakeLists.txt of all programs using A
• When you want a new global settings to be changed (compiler setting, predefined variable, C++ standard used), you need to update all your CMakeLists.txt

Then, I see two strategies to adress those issues and likely the one mentioned by OP.

1- Have CMakeLists.txt be well written and be smart enough not to have a frozen behaviourto update themselves on the fly. That's what we have in our software environment. Each module has a standardized file organization (sources are in src folder, includes are in inc folder...) and have simple text files to specify their dependencies (with keywords we defined, like QT to say the module needs to link with Qt). Then, our CMakeLists.txt is a two-line file and simply calls a cmake macro we wrote to automatically setup the module. As a MCVE that would be:

CMakeLists.txt:

include( utl.cmake )
add_module( "mylib", lib )

utl.cmake:

macro( add_module name what )
    file(GLOB_RECURSE source_files "${CMAKE_CURRENT_SOURCE_DIR}/src/*.cpp")
    include_directories(${CMAKE_CURRENT_SOURCE_DIR}/inc)
    if ( what STREQUEL "lib" )
        add_library( ${name} SHARED ${source_files} )
    elseif ( what STREQUEL "prg" )
        add_executable( ${name} ${source_files} )
    endif()
    # TODO: Parse the simple texts files to add target_link_libraries accordingly
endmacro()

Then, for all situations exposed above, you simply need to update utl.cmake, not the thousand of CMakeLists.txt you have...

Honestly, we are very happy with this approach, the system becomes very easy to maintain and we can easily add new dependencies, upgrade third parties, change some build/dependency strategies...

However, there remains a lot of CMake scripts to be written. And CMake script language sucks...the tool's very powerful, right, but the script's variable scope, the cache, the painful and not so well documented syntax (just to check if a list is empty you must ask for it's size and store this in a variable!), the fact it's not object oriented...make it a real pain to maintain.

So, I'm now convinced the real good approach may be to:

2- completly generate the CMakeLists.txt from a more powerful language like Python. The Python script would do things similar to what our utl.cmake does, instead it would generate a CMakeLists.txt ready to be passed CMake tool (with a format as proposed in HelloWorld, no variable, no function....it would only call standard CMake function).

I doubt such generic tool exists, because it's hard to produce the CMakeLists.txt files that will make everyone happy, you'll have to write it yourself. Note that gen-cmake does that (generates a CMakeLists.txt), but in a very primitive way and it apparently only supports Linux, but it may be a good start point.

This is likely to be the v2 of our software environment...one day.

Note : Additionally, if you want to support both qmake and cmake for instance, a well written Python script could generate both CMakeLists and pro files on demand!

Answer 3

Well i dont have much of an experience in Cmake either, but to perform a cross platform make a lot of files need to be written and modified including the CMakeLists.txt file, i suggest that you use this new tool called the ProjectGenerator Tool, its pretty cool, it does all the extra work needed and makes it easy to generate such files for 3'rd party sources with little effort. Just read the README carefully before using it.

Link: http://www.ogre3d.org/forums/viewtopic.php?f=1&t=54842

Answer 4

Not sure whether this is a problem original poster faced, but as I see plenty of „just write CMakefile.txt” answers above, let me shortly explain why generating CMakefiles may make sense:

a) I have another build system I am fairly happy with

(and which covers large multiplatform build of big collection of interconnected shared and static libraries, programs, scripting language extensions, and tools, with various internal and external dependencies, quirks and variants)

b) Even if I were to replace it, I would not consider cmake.

I took a look at CMakefiles and I am not happy with the syntax and not happy with the semantics.

c) CLion uses CMakefiles, and Cmakefiles only (and seems somewhat interesting)

So, to give CLion a chance (I love PyCharm, so it's tempting), but to keep using my build system, I would gladly use some tool which would let me implement make generate_cmake and have all necessary CMakefiles generated on the fly according to the current info extracted from my build system. I can gladly feed the tool/script with information which sources and headers my app consists of, which libraries and programs it is expected to build, which -I, -L, -D, etc are expected to be set for which component, etc etc.

Well, of course I would be much happier if JetBrains would allow to provide some direct protocol of feeding the IDE with the information it needs (say, allowed me to provide my own command to compile, to run, and to emit whatever metadata they really need - I suppose they mainly need incdirs and defines to implement on the fly code analysis, and libpaths to setup LD_LIBRARY_PATH for the debugger), without referring to cmake. CMakefiles as protocol are somewhat complicated.

Answer 5

I think that you are doing this upside down.

When using CMake, you are supposed to write the CMakeLists.txt yourself. Typically, you don't need to handle different compilers as CMake has knowledge about them. However, if you must, you can add code in the CMakeFiles to do different things depending on the tool you are using.

Answer 6

CLion is an Integrated development environment that is fully based on CMake project file.

It is able to generate itself the CMakeLists.txt file when using the import project from source

However this is quite probable that you have to edit this file manually as your project grows and for adding external dependency.