What is the proper way to document a CMake module? - 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

Related

How to build latex documentation with CMake?

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.

How to tell CPack to use the FreeBSD generator?

I have found several interesting links talking about a CPack generator for FreeBSD.
I would like to generate FreeBSD packages; however, whenever I attempt to generate TXZ archives (as directed by the instructions), the generated package isn't compatible with the pkg utility on FreeBSD. They miss the manifest file.
Obviously, CPack is generating raw archives, not pkg-ready archives. I assume I must be missing a step.
However, none of the links above talk about any such step.
Therefore,
How can I tell CPack to generate a FreeBSD-ready package?
(Original author of that code here)
So, there's two things in play here:
you need to be on FreeBSD (so that you have libpkg, which is needed to do the building)
you need to build the devel/cmake package with OPTIONS CPACK (which is not the default)
So:
cd /usr/ports/devel/cmake
make configure and select CPACK
make && make install
Then #Tsyvarev's comment will be the right answer. For the record, the support was deemed experimental, the library API unstable, and the pkg authors have asked me to re-vamp the code to use the current libpkg API so they can drop the old one. Time, though, is the limiting factor.

What markup language should I use for code included in comments to AUR packages website?

I could not find documentation anywhere for what syntax/markup to use for formatting code in comments to AUR packages.
The aurweb comments renderer can be seen at https://git.archlinux.org/aurweb.git/tree/aurweb/scripts/rendercomment.py?h=v4.6.0
It shows that the python-markdown library is used, with the fenced_code extension (triple backticks) enabled. Generally, most markdown should "just work".
It also includes a couple custom extensions to automatically linkify Arch Linux bug references or git commit hashes for the repository... there is nothing unusually out of the box here.

Is there any utility that can reformat a cmake file

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.

Where to place a shared utility module in OCaml?

I have a file Tools.ml which contains some common utility functions I write myself. Under .../Code/ I have several folders which each contains a project. My question is where I should place this Tools.ml such that all the folders and files under .../Code/ could share this module by Open Tools.
Hope my question is clear... Does anyone have a good solution?
Edit1: Following #gasche's answer, I have written tools.ml as follows:
module Tools =
struct
let a_function = ...
...
end
Then I compiled it, and done ocamlfind install tools META tools.cmo tools.cmx tools.ml as suggested, which looks going well. Then I have written test.ml as follows:
open Tools
let f = Tools.a_function
then I compiled it with ocamlc test.ml -o test, then I got an error:
File "test.ml", line 1, characters 0-1:
Error: Error while linking test.cmo:
Reference to undefined global `Tools'
Could anyone tell me what happened?
You could package it as an independent library, install it with other OCaml libraries, and access to it, from your project, as a library.
A very simple way to do this is to write a META file for ocamlfind. Create a directory somewhere you're comfortable to hold you "personal library" project. Suppose you have tools.ml and tools.mli, and your code depends on some findlib package (eg. unix and bigarray). You META would look like this:
name="tools"
description="personal collection of utilities"
version="0.1"
requires="unix,bigarray"
archive(byte)="tools.cmo"
archive(native)="tools.cmx"
Once you have written this META file, it is easy to ask ocamlfind to "install" the library (and remove it if you want to), and use it in your other projects. To install, the syntax is ocamlfind install <name> <meta-file> <file1> <file2> ... where <file1>, <file2>.. are the file you wish to see included in the installation directory. You must at least have tools.cmi tools.cmo (and tools.o and tools.cmx for native compilation), but it is good practice to also have tools.mli for example (and, if you want to provide the code, tools.ml).
ocamlfind install tools META tools.cmi tools.cmo tools.o tools.cmx tools.mli
(Of course tools.cmo etc. have to exist, that is you must install after you have compiled your package. If you have used ocamlbuild, they are likely to be in a _build subdirectory, so ocamlfind install ... _build/tools.cmo ....)
From your numerous projects, you can use your library easily, either using the ocamlfind toold directly if this is what you already do to compile your programs
ocamlfind ocamlc -package tools ....
or through the facilities provided by ocamlbuild for example, adding package(tools) to your tags.
To reinstall your library if you made a change to it and want it accessible from your projects
ocamlfind remove tools
ocamlfind install tools META ...
You could also handle all this through oasis, which is a layer on top of ocamlfind/ocamlbuild to automate this process. I'm not familiar enough with oasis to give such examples off the top of my head, but it should be equally simple for such a restricted case (one-file library), and scale better if you wish later to extend your library (eg. it can also handle documentation generation, pre-compilation configuration...).