Have Ubuntu systems fall back to build scripts for "Debian" if there isn't an "ubuntu" variant available.

[sp1ff]

Is your feature request related to a problem? Please describe.

I find myself specializing the build for Debian by just copying the Ubuntu files verbatim to files named p-$COMPONENT-linux-debian.inc. This works because Ubuntu & Debian share the same package manager (apt), but at the cost of replicating code.

Describe the solution you'd like

Update execution_action() to, on failure to find p-${component}-${OS}-${DISTRIBUTION}-${DISTRIBUTION_VER}.inc or p-${component}-${OS}-${DISTRIBUTION}.inc, check for a Debian variant, IFF ${DISTRIBUTION} = "Ubuntu". We should consider generalizing this: Mandrake could fall-back to Red Hat, Manjaro to Arch & so forth.

If this is of interest, I'd be happy to cut the PR myself.

[MartinNowack]

@sp1ff Thanks for opening this issue.

Here are my thoughts on this one:
For a sole user of KLEE, I find this script too much of a burden and would rather like to have distribution-specific packages.

For developing and testing KLEE under different setups (LLVM versions, LLVM configurations, ... ), the script is useful.
If you would like to extend it in this context, I'm happy to review PRs and provide input.
In general, I would rather try to keep the main script (build.sh) simple and as distribution agnostic if possible.
My suggestion, expand check_os() to detect variants. Also, maybe we can get repurpose VER part as a version number and instead use it as VAR like variant. Currently, there is only one VER usage (p-clang-linux-ubuntu-22.04) and this could be refactored into the more general p-clang-linux-ubuntu partial script.

Let me know if anything is unclear.

[sp1ff]

Thanks, @MartinNowack. Definitely agree that the distribution-specific package is preferable for casual users.
I'm not quite following your VAR proposal, however. Could you say a bit more? For instance, what would the Debian clang partial script that could be picked-up on Ubuntu be named?

[MartinNowack]

The basic idea of the script is to try from the most specific instructions to the least specific instructions until one matching file is found, i.ep-${component}-${OS}-${DISTRIBUTION}-${DISTRIBUTION_VER}.inc.

The script will first try:

• p-clang-linux-ubuntu-22.04
• p-clang-linux-ubuntu
• p-clang-linux

We are currently not really using the "version" part, 22.04.
The changes between different releases are smaller than expected and one could integrate this into the distribution-specific checks.

Instead, one could detect Distribution and Variant, i.e. Ubuntu and Debian and use this to differentiate as required, i.e.:

• p-clang-linux-ubuntu-debian
• p-clang-linux-ubuntu
• ...

(I'm just ignoring the fact of which distribution is a variant of another for the simplicity of this discussion.)

Hence, we might get away with just detecting the right OS/distribution and propagating them as part of the file structure.

Let me know what your thoughts are.

[sp1ff]

Ah, I see. So my idea was that the "debian" file would contain things that applied to Debian and all Debian-derived distros. In other words, it could be picked-up on Ubuntu and Mint, for example. Hence the "most-derived" distribution name would not be a part of the file name.
Instead, consider a search sequence like:

• p-clang-linux-ubuntu-22.04
• p-clang-linux-ubuntu
• p-clang-linux-debian
• p-clang-linux

Whereas on Mint, it would be:

• p-clang-linux-mint-21.3
• p-clang-linux-mint
• p-clang-linux-debian
• p-clang-linux

Notice that p-clang-linux-debian appears in both sequences.
TBH, as I think this through in more detail, I see that it could get complicated quickly. For instance, Linux Mint is actually an Ubuntu derivative, so should it fall back the Ubuntu file first, and then Debian? Not to mention the hassle of constantly updating the code to account for different distros and their genealogies. It's starting to feel to me like the "install' scripts that were predominant in the nineties before GNU Autotools really took over.
Perhaps a little code replication is taking out a bit of tech debt while you see how the system gets used in practice.