This PR:
Establishes clear boundaries for the project's recommended build and testing environments.
Adds a CI job that tests the project's minimum recommended build environment.
This is useful for reviewing changes like #1865 or #1869.
For the context:
... Wheezy is just ancient. Do you think a Docker image that depends on a generic Debian oldoldstable image could do the job? (Does such an image exist?) This would at least save us from bumping the version regularly.
Establish clear boundaries for the project's recommended build and
testing environments.
Debian "oldoldstable" is the minimum recommended build environment.
Rebased on top of the recent CI changes.
102 | + 103 | +The project is intended to be portable to any system with a C89/C90-compatible toolchain. 104 | +Additionally, the C standard library must provide the `<stdint.h>` header. 105 | + 106 | +Toolchains older than the default one shipped in the current Debian "oldoldstable" release 107 | +are not tested and are not recommended for building the project.
I think we should remove this sentence (and change the PR title accordingly).
I agree. I'm not sure there's much value (for this project) in trying to establish a minimum supported compiler version, and it seems possible that tests for this are going to add more friction than value. As long as they are low-effort, and can be deleted/changed easily, probably fine.
I'd also say that if we were going to document something, just state the particular compiler, rather than make people look up what compiler/version pair happened to ship on an old version of some Linux distro.
I'd also say that if we were going to document something, just state the particular compiler, rather than make people look up what compiler/version pair happened to ship on an old version of some Linux distro.
No strong opinion here but I still I tend to simply say "oldoldstable". Then we won't run into the need to bump the version regularly (e.g., because something breaks on an old compiler/docker image) and worse, use our brain cycles to make a decision whether the bump is justified without clear guidelines.
95 | @@ -97,8 +96,15 @@ This can be done with the following steps: 96 | Subkey fingerprint: 4BBB 845A 6F5A 65A6 9DFA EC23 4861 DBF2 6212 3605 97 | ``` 98 | 99 | -Building with Autotools 100 | ------------------------ 101 | +## Building from source
nit:
## Building
Maybe it's just me, but "building from source" sounds like this is a special thing and we also ship binaries.
see my "code" suggestion: Just "Building"
12 | + apt-get clean && rm -rf /var/lib/apt/lists/* 13 | + 14 | +ENV VIRTUAL_ENV=/root/venv 15 | +RUN python3 -m venv $VIRTUAL_ENV 16 | +ENV PATH="$VIRTUAL_ENV/bin:$PATH" 17 | +RUN pip install lief
I think we should omit python from this job to simplify maintenance. We don't want to be restricted to whatever Python version oldoldstable ships (and who knows if lief will runs on that version in the future).
Disabling Python would require more changes in this PR to handle the testvectors build target, similar to 071523b2ceec9d10d53915ebbe942ccaf194d086.
Hm, yeah. I was thinking we can just set SYMBOL_CHECK=no, but I forgot about the test vectors. Though I can we could also have TEST_VECTORS variable that is enabled by default. That would just change a single line in the script.
Weak Concept ACK (if we remove the "recommendation part") -- I think it's a useful test and the maintenance burden will be okay @fanquake I wonder what you think from with your maintainer hat on.
@hebasto Have you checked if the new Docker image fits in the GHA cache (together with the existing cache artifacts)?