Qyriad
b81eec6ed5
This commit adds the capability for building the Doxygen internal API
docs in the Meson buildsystem, and also makes doing so the default for
the internal-api-docs hydra job. Aside from the /nix-support directory,
which differed only by the hash part of a store path, the outputs of
hydraJobs.internal-api-docs before and after this commit were
bit-for-bit identical on my machine.
Change-Id: I98f0017891c25b06866c15f7652fe74f706ec8e1
100 lines
3.7 KiB
INI
100 lines
3.7 KiB
INI
# Doxyfile 1.9.5
|
|
|
|
# The PROJECT_NAME tag is a single word (or a sequence of words surrounded by
|
|
# double-quotes, unless you are using Doxywizard) that should identify the
|
|
# project for which the documentation is generated. This name is used in the
|
|
# title of most generated pages and in a few other places.
|
|
# The default value is: My Project.
|
|
|
|
PROJECT_NAME = "Nix"
|
|
|
|
# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
|
|
# could be handy for archiving the generated documentation or if some version
|
|
# control system is used.
|
|
|
|
PROJECT_NUMBER = @PACKAGE_VERSION@
|
|
|
|
OUTPUT_DIRECTORY = @docdir@
|
|
|
|
# Using the PROJECT_BRIEF tag one can provide an optional one line description
|
|
# for a project that appears at the top of each page and should give viewer a
|
|
# quick idea about the purpose of the project. Keep the description short.
|
|
|
|
PROJECT_BRIEF = "Nix, the purely functional package manager; unstable internal interfaces"
|
|
|
|
# If the GENERATE_LATEX tag is set to YES, doxygen will generate LaTeX output.
|
|
# The default value is: YES.
|
|
|
|
GENERATE_LATEX = NO
|
|
|
|
# The INPUT tag is used to specify the files and/or directories that contain
|
|
# documented source files. You may enter file names like myfile.cpp or
|
|
# directories like /usr/src/myproject. Separate the files or directories with
|
|
# spaces. See also FILE_PATTERNS and EXTENSION_MAPPING
|
|
# Note: If this tag is empty the current directory is searched.
|
|
|
|
# FIXME Make this list more maintainable somehow. We could maybe generate this
|
|
# in the Makefile, but we would need to change how `.in` files are preprocessed
|
|
# so they can expand variables despite configure variables.
|
|
|
|
INPUT = \
|
|
src/libcmd \
|
|
src/libexpr \
|
|
src/libexpr/flake \
|
|
tests/unit/libexpr \
|
|
tests/unit/libexpr/value \
|
|
tests/unit/libexpr/test \
|
|
tests/unit/libexpr/test/value \
|
|
src/libexpr/value \
|
|
src/libfetchers \
|
|
src/libmain \
|
|
src/libstore \
|
|
src/libstore/build \
|
|
src/libstore/builtins \
|
|
tests/unit/libstore \
|
|
tests/unit/libstore/test \
|
|
src/libutil \
|
|
tests/unit/libutil \
|
|
tests/unit/libutil/test \
|
|
src/nix \
|
|
src/nix-env \
|
|
src/nix-store
|
|
|
|
# If the MACRO_EXPANSION tag is set to YES, doxygen will expand all macro names
|
|
# in the source code. If set to NO, only conditional compilation will be
|
|
# performed. Macro expansion can be done in a controlled way by setting
|
|
# EXPAND_ONLY_PREDEF to YES.
|
|
# The default value is: NO.
|
|
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
|
|
|
MACRO_EXPANSION = YES
|
|
|
|
# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES then
|
|
# the macro expansion is limited to the macros specified with the PREDEFINED and
|
|
# EXPAND_AS_DEFINED tags.
|
|
# The default value is: NO.
|
|
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
|
|
|
EXPAND_ONLY_PREDEF = YES
|
|
|
|
# The INCLUDE_PATH tag can be used to specify one or more directories that
|
|
# contain include files that are not input files but should be processed by the
|
|
# preprocessor. Note that the INCLUDE_PATH is not recursive, so the setting of
|
|
# RECURSIVE has no effect here.
|
|
# This tag requires that the tag SEARCH_INCLUDES is set to YES.
|
|
|
|
INCLUDE_PATH = @RAPIDCHECK_HEADERS@
|
|
|
|
# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then this
|
|
# tag can be used to specify a list of macro names that should be expanded. The
|
|
# macro definition that is found in the sources will be used. Use the PREDEFINED
|
|
# tag if you want to use a different macro definition that overrules the
|
|
# definition found in the source code.
|
|
# This tag requires that the tag ENABLE_PREPROCESSING is set to YES.
|
|
|
|
EXPAND_AS_DEFINED = \
|
|
DECLARE_COMMON_SERIALISER \
|
|
DECLARE_WORKER_SERIALISER \
|
|
DECLARE_SERVE_SERIALISER \
|
|
LENGTH_PREFIXED_PROTO_HELPER
|