Initial build system support deficiencies

Things to be fixed:

  1. The API is toast, since the plugin provider needs to defer initialization, which is annoying and sad. The API should be rewritten such at __init__ can expect to see all it needs to see (including configure args, build-dirs, etc., which should be provided pre-resolved - this implies running the constructor in the relevant environment). Possible feature interaction with 6.
    • Simplest solution is probably to have two-levels of initialization. One inside the environment with everything expanded and one outside the environment. The latter would be used by the linting but is also necessary to define the environment to be used.
    • The debputy API should provide a default one for the "outside" variant with a few hooks since most of it should be generic.
  2. Each build re-initialize the environment from scratch, including invoking dpkg-buildflags. That is slow and we should cache this a lot better when it is the same environment (the default environment is an obvious win)
  3. Conditional for skipping/running tests or ignoring errors from tests. Like:
    • "Never run the tests
    • "Never run the tests on !linux-any"
    • "Run the tests but ignore errors on !linux-any"
  4. HOME and XDG envs are not set/unset like debhelper does it.
  5. Conditionally skip steps like Do the configure, but instead of the build then run this command instead. Combine with before and after steps (autoconf + debhelper build systems want to split their configure step to have autoreconf separate). Problem: Environment is not known until the build system is constructed as it is.
    • Note: hooks in debhelper could apply to different package sets (for) than the step they hook into or replaced. Consider a build that apply to all packages but have different -arch/-indep overrides to build code vs. docs as a minimum supported feature.
  6. Build systems should be able to report build-dependencies required. This will require instantiating the build system (since cmake + makefile requires different dependencies than cmake + ninja and the build system would not know which it is until it has parsed its config). Things to consider:
    • Parts of the build system would have to be "LSP/lint safe" (initialization, auto detection and requirement detection). This also might feature interact with 1.
    • LSP/Lint would need to parse the build system logic or the entire manifest parsing must be LSP/lint safe.
    • Perl packages building XS modules to should have perl-xs-dev (not conditional on cross-building)
    • CMake consumers needs cmake and conditionally ninja-build
    • Meson consumers need meson (and arguably ninja-build but I think we de facto assume meson to provide it)
    • The debhelper build system would need debhelper-compat (= N) | debhelper (any version).
    • The qmake build systems would require the relevant version of qmake.
  7. Automatic destdir -> default search path is missing
  8. Collect automatic destdir earlier (in build-env rather than outside)
  9. Package selection (for) uses list of package names. However, selections are not always by package name but rather arch:all vs. arch:any or deb vs. udeb.
Edited by Niels Thykier