f7f37035c8
Today, with the tests inside a `tests` intermingled with the
corresponding library's source code, we have a few problems:
- We have to be careful that wildcards don't end up with tests being
built as part of Nix proper, or test headers being installed as part
of Nix proper.
- Tests in libraries but not executables is not right:
- It means each executable runs the previous unit tests again, because
it needs the libraries.
- It doesn't work right on Windows, which doesn't want you to load a
DLL just for the side global variable . It could be made to work
with the dlopen equivalent, but that's gross!
This reorg solves these problems.
There is a remaining problem which is that sibbling headers (like
`hash.hh` the test header vs `hash.hh` the main `libnixutil` header) end
up shadowing each other. This PR doesn't solve that. That is left as
future work for a future PR.
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
(cherry picked from commit 91b6833686a6a6d9eac7f3f66393ec89ef1d3b57)
(cherry picked from commit a61e42adb528b3d40ce43e07c79368d779a8b624)
68 lines
2.4 KiB
INI
68 lines
2.4 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 \
|
|
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
|
|
|
|
# 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@
|