forked from lix-project/lix
be81764320
This introduces some shared infrastructure for our notion of protocols. We can then define multiple protocols in terms of that notion. We an also express how particular protocols depend on each other. For example, we can define a common protocol and a worker protocol, where the second depends on the first in terms of the data types it can read and write. The "serve" protocol can just use the common one for now, but will eventually need its own machinary just like the worker protocol for version-aware serialisers
94 lines
3.6 KiB
INI
94 lines
3.6 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@
|
|
|
|
# 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 \
|
|
src/libexpr/tests \
|
|
src/libexpr/tests/value \
|
|
src/libexpr/value \
|
|
src/libfetchers \
|
|
src/libmain \
|
|
src/libstore \
|
|
src/libstore/build \
|
|
src/libstore/builtins \
|
|
src/libstore/tests \
|
|
src/libutil \
|
|
src/libutil/tests \
|
|
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
|