I'm trying to stitch together doxygen and sphinx using breathe.
breathe requires you generate doxygen xml output first though: https://breathe.readthedocs.io/en/latest/quickstart.html
I don't want to do this in a separate step. Can I just have sphinx-build execute doxygen for me on build? I just need it to run this command first with some args. Is this possible without having to write a custom sphinx plugin?
EDIT
This works
# Need to sleep because sometimes doxygen doesnt finish writing files before sphinx runs
cwd = os.path.dirname(os.path.realpath(__file__))
os.system('doxygen')
time.sleep(3)
Sure, Sphinx will execute whatever Python code you add to its configuration file conf.py before it starts the documentation build process.
From the Sphinx documentation:
The configuration file is executed as Python code at build time (using importlib.import_module(), and with the current directory set to its containing directory), and therefore can execute arbitrarily complex code. Sphinx then reads simple names from the file’s namespace as its configuration.
Which means pre-build tasks can simply be implemented by running the external program, such as Doxygen in your case, as a subprocess anywhere in conf.py.
Related
From the docs:
https://snakemake.readthedocs.io/en/stable/executable.html
Currently, this mode requires that the Snakemake workflow is stored in a git repository. Snakemake uses git to query necessary source files (the Snakefile, scripts, config, …) for workflow execution and encodes them into the kubernetes job.
However, what is not clear to me is how to specify source files as stated. srcdir returns the absolute path with the specified prefix prepended.
Could someone please point me to the relevant area of the docs please!
Thanks
I haven't worked with kubernetics and Snakemake, but I am assuming using the 'default' structure should work. You can easily generate this structure with the snakemake cookiecutter repo:
https://github.com/snakemake-workflows/cookiecutter-snakemake-workflow
Just make sure cookiecutter is installed and you can run this on the command-line:
cookiecutter https://github.com/snakemake-workflows/cookiecutter-snakemake-workflow
Or you can always just take a look at where files are stored in that repo and copy the structure.
We have a set of Ansible modules on GitHub (https://github.com/zhmcclient/zhmc-ansible-modules) and can generate HTML documentation from it using Sphinx. However, the build process includes a step where a documentationgenerator tool from Ansible is run to generate .rst files from the Python module source.
We have set up an RTD project for this (http://zhmc-ansible-modules.readthedocs.io/), but that extra step is not run there, of course.
-> How can we get that extra step run within the build process that runs on RTD?
RTD does not support intermediary steps in its build process. You must provide source files in your repository that are ready to be rendered. See RTD Build Process.
I'm trying to port a *nix, CMake-based project to Windows. One header file needed by the main library is generated by a custom program, so the CMakeLists.txt file contains something like this:
add_executable(TableGenerator "TableGenerator.cpp")
target_link_libraries(TableGenerator ${LibFoo_LIBRARY})
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
An important detail is that TableGenerator uses the external shared library LibFoo. For example under Linux, everything works fine, because libfoo.so is installed in one of the system library directories like /usr/local/lib, or CMake even sets the rpath attribute in the executable, saying where exactly to find the library.
On Windows, however, these kind of libraries are usually not installed into the system but are rather just extracted or compiled into some arbitrary directory in or near the build tree. In order for TableGenerator to run, the foo.dll would need to be available in or copied to one of the Dynamic-Link Library Search Order paths (say %WINDIR%\System32 or the build output directory for TableGenerator), which is not desirable.
How can I set the PATH environment variable for the custom command, i.e. to be used not during the CMake run but during the actual custom build step runtime?
While still doing my research in order to ask the question properly, I have found three solutions. Considering how hard it was to find this information, I decided to post the question and answer here anyway.
1. Using global variable CMAKE_MSVCIDE_RUN_PATH
There is a special variable dedicated to solving this exact problem – CMAKE_MSVCIDE_RUN_PATH. If set, it results in a line like this being added to the custom build step script:
set PATH=<CMAKE_MSVCIDE_RUN_PATH>;%PATH%
So all that's needed then is something like this at a good place:
set(CMAKE_MSVCIDE_RUN_PATH ${LibFoo_RUNTIME_LIBRARY_DIRS})
I have originally noticed this variable only in CMake sources, because it used to be undocumented until CMake 3.10. So you might not be able to find it in documentation for older versions of CMake, but don't worry, it's been supported since 2006.
Advantages:
▪ Can be enabled at one central place
▪ No change at all in any of the add_custom_command() commands elsewhere is needed
▪ Only the path itself is set, no batch commands need to be written explicitly
▪ The obvious choice with clear name and intent
Disadvantages:
▪ Global for the whole CMake project and all custom commands
▪ Works with the "Visual Studio 9 2008" and above generators only
2. Setting the PATH explicitly using two COMMAND parameters
The script being generated for the custom build step in Visual Studio contains some prologue, then the commands themselves and then some epilogue. Wouldn't it be possible to simply add set PATH=... before the real command through another COMMAND parameter?
The documentation for add_custom_command() says:
COMMAND
Specify the command-line(s) to execute at build time. If more than one COMMAND is specified they will be executed in order, but not necessarily composed into a stateful shell or batch script.
So no, that's not guaranteed to be possible. But the Visual Studio project generator actually does it like this, i.e. the individual commands are just appended one after another, so the following does the job:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND set "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%"
COMMAND TableGenerator "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
Advantages:
▪ The PATH can be changed for each custom command explicitly
Disadvantages:
▪ Relies on an undocumented behavior of the generator
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
3. Using file(GENERATE ...) to create a custom script
The documentation for add_custom_command() quoted above continues:
To run a full script, use the configure_file() command or the file(GENERATE) command to create it, and then specify a COMMAND to launch it.
This is a bit messy because of the additional temporary files and commands:
file(GENERATE OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd"
CONTENT "set PATH=${LibFoo_RUNTIME_LIBRARY_DIRS};%PATH%
%1 ${CMAKE_CURRENT_BINARY_DIR}/Table.h")
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND "${CMAKE_CURRENT_BINARY_DIR}/RunTableGenerator.cmd" "$<TARGET_FILE:TableGenerator>"
DEPENDS TableGenerator)
Notice the awkward way of sending the path to the executable as an argument. This is necessary because the script is writen once, but TableGenerator might be in different locations for different configurations (debug and release). If the generator expression was used directly in the content, a CMake error would be printed and the project would not build correctly for all but one configuration.
Advantages:
▪ The PATH can be changed for each custom command explicitly
▪ A fully documented and recommended solution
Disadvantages:
▪ Very noisy in the CMakefiles
▪ It's necessary to rewrite the whole command for Windows and keep both versions in sync
▪ Each custom command must be changed explicitly
4. Launch the custom command through CMake wrapper
See the other answer below contributed by Dvir Yitzchaki.
I had personally settled on the solution #1 because it was clean and simple, even before it got properly documented and supported by CMake in version 3.10. It should be the best way forward for you as well, unless you need to do something even more special.
There is another way besides what Yirkha wrote and that is to run the executable through cmake and use cmake's -E option to set the environment.
So in your case it will be:
add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
COMMAND ${CMAKE_COMMAND} -E env "PATH=${LibFoo_RUNTIME_LIBRARY_DIRS}" $<TARGET_FILE:TableGenerator> "${CMAKE_CURRENT_BINARY_DIR}/Table.h"
DEPENDS TableGenerator)
See http://www.cmake.org/pipermail/cmake/2006-March/008522.html for details.
I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.
I want to use oclint (an Objective-C static analyzer) for my projects but the official documentation does not clearly describe how to configure it.
How do I use it?
I have installed the oclint package then copied the script for capturing projects configs into a project's folder. Running this script creates an empty file named compile_commands.json and it does not fill xcodebuild.log with any data.
Thank you!
I don't think this script will add anything into xcodebuild.log. It reads from it. You may want to manually run xcodebuild and save the output into xcodebuild.log before running the script.
Check out the documentation.
I have had luck with the manual route of copying the script into my project's folder then executing it on the command line.
Though this does not integrate oclint's functionality into XCode, it does provide feedback via stdout.
From this feedback I then update my code to align with oclint's recommendation and iteratively run oclint until my code complies with oclint's rules.