Build system design

Adding build systems to debputy

Some high level requirements:

• Support multiple builds/flavors from #31
• Support multiple environments (one per build/command) per from #100. Potentially, builds can expose a hook for a separate env for tests.
• Auto-detection by default (simple packages using "all defaults" should not require a manifest).
• Interleaving of custom commands/shell scripts and build systems (see #31)
• Complication: Substitution into shell like input should be shell escaped by default but (per variable) support being a raw (textual) substitution.

Some build system specific ideas/challenges:

• clean should ideally work even if the user manually ran a build like it does in debhelper.
• The clean rule should ideally be implemented automatically by debputy for most build systems (where possible). This partly conflicts with the previous item for in-source builds.
• User might need custom clean code and that might need interleaving with the build system.
• Build systems should be able to expose hooks similar to execute_{before,after}_dh_auto_... where people can provide custom logic/commands.
• Build systems should be able to provide extension points where the user can provide configuration (like command line options for the configuration command).

Small sample:

build:
 autoconf:
     before-reconf: ./custom-prestep
     configure-options: '--with-foo --with-bar "--enable=complex value"'
     test-rule:
       skip-tests-when:  # Manifest condition
         arch-matches: "i386"

# Assumes default clean is sufficient.

Curl based sample:

builds:
# ... TODO

Custom build sample:

builds:
 custom:
   # source-directory: some-dir
   # build-directory: some-dir/_build
   configure: ./run configure  # Uses source dir as cwd
   build: ./run build ...
   tests: ./run tests
   install: "./installer DEST_DIR={{DEST_DIR}}"
   # clean: ./run clean  # Uses source dir as cwd