I have relatively complex cmake files and I am wondering if there is any utility that can reformat a cmakeList.txt and beautify it for easier reading?
Some simple tricks would do the jobs, such as indenting if else endif sections and so on.
Is there any such tools?
I am using notepad++ for editing, but if there is any other tools, I can switch.
Someone recently wrote a CMake autoformatter called cmake_format. Still under development but should be good enough for basic CMake files.
I searched for a code beautifier supporting CMake, and I did not find any.
There is this thread on CMake mailing lists, which does not provide a good solution
This mailing list thread provides no answer too (some use emacs mode)
I checked most of the major code beautifiers using UniversalIndentGUI on Ubuntu. None of the provided beautifiers from the long list are working with CMake out of the box.
Looks like implementing CMake support in an existing beautifier, or writing a custom one is a great idea for a nice code project.
Take a look at Atom and its plugin language-cmake (you can install easily with Atom package manager).
Once both are installed, open your CMakeLists.txt and go to Edit > Lines > Auto Indent.
In case it is not clear from the other answers and comments.
In Ubuntu (Debian?) there is a tool called cmake-format, which seems to be what is called cmake_format in other answers.
And it worked very well for me.
$ apt search cmake-format
Sorting... Done
Full Text Search... Done
cmake-format/kinetic,kinetic,now 0.6.13-2 all [installed]
source code formatter for cmake listfiles
$ cmake-format --help
usage:
cmake-format [-h]
[--dump-config {yaml,json,python} | -i | -o OUTFILE_PATH]
[-c CONFIG_FILE]
infilepath [infilepath ...]
Parse cmake listfiles and format them nicely.
...
The specification file is quite difficult to understand but I liked the default formatting anyway.
The best part is that it seems to normalize the capitalization of keywords which is what drives me crazy.
Related
Situation:
a small CMake C++ project
with a /doc folder, currently built via a custom Makefile in it.
Problems:
CMake and GNU make are two separate build systems and it is laughable to use more than one for a small and simple project.
make help does not list a doc target
Tried solutions:
Googled the problem, got suggested to use add_custom_target(). That sounds like the wrong solution because regenerating the target .pdf every time is ... I can't call it "inefficient" as it takes a couple of seconds. But is against C++'s ideal of "pay for only what you use" - yes.
How to generate documentation from .tex files given a working makefile is already present? With CMake.
A quick Google search (...actually many rather extensive Google searches) have not been able to explain how to properly document a CMake module.
What I'm looking for is a way to document custom CMake modules so that they work with the cmake --help-module <module_name> command. Is there any standard way of doing this? Can anyone point me to some good examples? The documentation process seems oddly.... not well documented. Haha.
How are modules that work with cmake --help-module documented?
Any help is appreciated.
Quote from an email response I got from Brad King (member of the CMake Developers email list):
There is no way to do this. The only reason --help-module exists
at all is because prior to 3.0 the documentation was generated by
the CMake binary itself, and people were used to the option being
available. It is only for builtin modules and only available for
legacy reasons, and may one day go away in favor of the man pages
and html docs.
The online docs, like those at https://cmake.org/cmake/help/v3.14
do publish a /objects.inv to support intersphinx:
http://www.sphinx-doc.org/en/master/usage/extensions/intersphinx.html
This was done on request of some users so I haven't looked into how
that works, but one should be able to use sphinx to generate one's
own documentation and still cross-reference CMake's online docs.
If you get that working we'd welcome a MR to add docs describing how,
perhaps in
https://gitlab.kitware.com/cmake/cmake/blob/master/Help/dev/documentation.rst
It sounds like using Sphinx is the way to go.
Additional info:
How does Sphinx know to go parse that ".cmake" file? Does Sphinx recognize the "cmake-module" keyword in a special way and know what to do with it?
it’s from a Sphinx module that you can find the in the CMake sources Utilities/Sphinx/cmake.py. Or you can install this file using pip:
pip install sphinxcontrib-moderncmakedomain
When configuring Sphinx, you have to name the extensions to use in Sphinx's configuration file (conf.py) and add the name of the extension (sphinxcontrib.moderncmakedomain) to the extensions array.
Good news: You can use sphinx to document your CMake Modules, and at the same time use Doxygen to document your C++ (or other) source code.
I created an example project which shows how to use the sphinxcontrib-moderncmakedomain in combination with Sphinx and Doxygen to generate Documentation for your C++ Code AND CMake code:
https://gitlab.com/Pro1/doxygen-cmake-sphinx
It is using the sphinxcontrib-moderncmakedomain package and CMake itself to configure the sphinx conf.py and then run sphinx.
The example is heavily based on the official CMake Documentation from: https://gitlab.kitware.com/cmake/cmake/-/tree/master/Utilities/Sphinx
I'd like to access a dynamic library using FFI features in the Ren-C Rebol branch. I understand this is possible by building with LibFFI support enabled. What steps do I need to take to enable this?
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
(Note: This is probably the kind of information that should be added to the Wiki, as it is not so much a language question but the kind of thing that is subject to change over time. But, answerable, so...)
If you're using the GNU make method to build (where make -f makefile.boot generates a makefile for you) then you should find some lines in there like:
TO_OS_BASE?= TO_OSX
TO_OS_NAME?= TO_OSX_X64
OS_ID?= 0.2.40
BIN_SUFFIX=
RAPI_FLAGS= -D__LP64__ -DENDIAN_LITTLE -DHAS_LL_CONSTS -O1 ...
HOST_FLAGS= -DREB_EXE -D__LP64__ -DENDIAN_LITTLE ...
Modify the RAPI_FLAGS and HOST_FLAGS lines at the beginning to add -DHAVE_LIBFFI_AVAILABLE. That (-D)efines a preprocessor directive to tell the code it's okay to generate calls to FFI, because you have it available for linking later.
Now to tell it where to find include files. There's a line for includes that should look like:
INCL ?= .
I= -I$(INCL) -I$S/include/ -I$S/codecs/ ...
To the tail of that you need to add something that will look like -I/usr/local/opt/libffi/lib/libffi-3.0.13/include, or similar. The actual directory will depend on where you have libffi on your system. On the OSX system I'm looking at, that has two files in it, ffi.h and ffitarget.h.
(Note: I'm afraid I don't know how these files got on this computer. They didn't ship with the OS, so they came from...somewhere. I don't generally develop on OSX--nor for that matter do I use this FFI. You'll have to consult your local FFI-on-OSX website, or perhaps for support contact Atronix Engineering) who added the FFI features to Rebol.)
Then it's necessary to tell it where you have libffi on your system. You'll find a CLIB line that is likely just CLIB= -lm. You'd change this for example to:
CLIB= -L/usr/local/opt/libffi/lib -lm -lffi
-lffi Tells it to look for the ffi (-l)ibrary, and -lxxx means it assumes the name of the library will be libxxx[something]. -L/usr/local/opt/libffi/lib tells it where to look for it. You'll have to figure out where (if anywhere) you have libffi, and if not get it. If you had it, the directory would have contents something like:
libffi-3.0.13
libffi.6.dylib
libffi.a
libffi.dylib
pkgconfig
I mainly use OS X for development, though would also like to be able to build it for use with Linux.
On Linux it's similar but generally much easier to get the library, as easy as sudo apt-get install libffi-dev. Same step for the RFLAGS and CFLAGS, and it should take care of the location automatically... so you can add just -lffi to CLIB.
Old notes from me:
cat steps-for-lib-ffi-osx
Install libfffi via homebrew
brew install libffi
Add /use/include/libffi to the -I in the generated makefile
Add /usr/local/Cellar/libffi/3.0.13/lib/libffi.a to the OBJS in the
generated makefile
The version 3.0.13 may vary
I am asking because I would like to enable syntax highlighting for CMakeCache.txt in my text editor (GNU Emacs).
Turning my comments into an answer
There was a post My Customized cmake-mode.el includes support for CMakeCache.txt back in 2007, so I'm not sure if it is still valid.
Generally speaking the CMakeCache.txt does not follow the normal CMake script syntax and maybe "topic to change".
So it's recommended to Use a CMake GUI or the wizard mode (cmake -i) to edit cache entries.
After compiling with CMake with flags --coverage, and running my boost unit test programs, files with extension .cpp.gcda and .cpp.gcno are created. If I then run gcovr it claims it cannot find the .gcno files (error message ".gcno:cannot open graph file"). I could possibly move all output files but that would be really awkward/silly.
Related problems of other people could be solved by using CTest but as I am using Jenkins I'd like to stick to gcovr and use the cobertura xml output.
Ps. Maybe I should simply ask: how should I combine CMake with gcovr?
This is the solution we are using for the same setup inside jenkins: http://www.semipol.de/archives/320. You can simply grab the CMake macro from the linked RSC library for your own purposes.
Apart from that read something about a slightly changed format of the coverage files in recent gcc versions and it seems gcovr didn't keep up with that. But I cannot remember where I read this.