Dockerizing the lnav Build Process

[ba-didi]

I'm exploring ways to simplify the lnav build process and improve the developer experience. One area I've been looking at is leveraging Docker more effectively. While the current musl Dockerfile serves a specific purpose in the 'bins' action, I believe it could be generalized and used more widely for both CI and development builds.

Currently, the README build instructions can be challenging to follow, and setting up the required dependencies can be time-consuming. Using Docker for all build stages would address these issues and offer several benefits:

• Consistent Environments: Developers and CI builds would use the same environment, reducing environment-related bugs.
• Simplified Setup: New developers would only need to install Docker.
• Possibly Faster CI: Sharing Docker images (or layers) across jobs like ci-build/coverage, ci-build/build, etc., could potentially reduce build times by leveraging Docker's caching.
• Easier Dependency Management: Environment changes would be handled in the Dockerfile, not on individual developer machines.
• Improved 'bins' Action: Given that the ci-build stage already builds with static libraries (for portability/smaller size?), this could be leveraged in the 'bins' action, perhaps by caching the resulting binaries.
• Shift Build Requirements: Tasks like dependency checking and Rust package installation could be moved to the Docker build stage.

My proposed approach involves:

• Refactoring configure.ac to support building lnav with only static libraries (and other necessary flags for creating the bins artifact). Potentially separating these into two options: one for the portable static build and one for other optimizations.
• Making the "musl" Dockerfile more flexible to run individual commands (autogen, configure, make) with parameters.
• Using this Docker image for all CI actions, especially ci-build.
• Providing Docker Compose or scripts to simplify development builds with mounted volumes.

@tstack, would you be open to exploring this approach? I'd be happy to contribute a proof-of-concept demonstrating these changes.

[tstack]

I've never used docker for development, so I don't really have a feeling one way or the other. If you want to give it a go, feel free. So long as the CI builds work I will merge the changes.

I will point out that there is a CMake build configuration for lnav as well. That build depends on vcpkg for getting libraries. So, theoretically, it's a bit simpler. I don't ship the binary it produces since it has a couple of goofy bugs, like some library is printing out some debug crud. I also haven't mirrored all of the test infrastructure, only the autoconf/automake build runs all the tests.

(I keep the CMake build around to keep CLion happy)

[ba-didi]

@tstack, I'd appreciate your insights on the lnav build configuration.

To streamline the Docker build process, I'd like to clarify the purpose of each option in the configure script. My goal is to categorize these options into:

1. Those strictly necessary for a static build.
2. Those that optimize the release build, such as reducing memory usage.

Then, I plan to create distinct flags for each category, with the static build configuration as the Docker default.

Here's the relevant configure call from entrypoint.sh:

../configure \
    --with-libarchive=/fake.root \
    CFLAGS='-static -g1 -gz=zlib -no-pie -O2' \
    CXXFLAGS='-static -g1 -gz=zlib -U__unused -no-pie -O2' \
    LDFLAGS="-L/fake.root/lib" \
    CPPFLAGS="-I/fake.root/include -I/fake.root/include/ncursesw" \
    LIBS="-L/fake.root/lib -lssh2 -llzma -lssl -lcrypto -lz -llz4" \
    --enable-static \
    PATH="/fake.root/bin:${PATH}"

My current understanding is:

• /fake.root serves as the root for static libraries and headers.

• --with-libarchive=/fake.root, CFLAGS='-static -no-pie', CXXFLAGS='-static -no-pie', LDFLAGS="-L/fake.root/lib", CPPFLAGS="-I/fake.root/include -I/fake.root/include/ncursesw", LIBS="-L/fake.root/lib", LIBS="-llzma -llz4", and --enable-static are all related to the static build (category 1).

• CFLAGS='-g1 -gz=zlib -O2' and CXXFLAGS='-g1 -gz=zlib -O2' are for release optimizations (category 2).

• I'm unsure about the purpose of CXXFLAGS='-U__unused', LIBS="-lssh2 -lssl -lcrypto -lz", and PATH="/fake.root/bin:${PATH}". My testing indicates lnav compiles correctly without them. Could these be safely removed?

Could you please confirm my categorization and advise on the removal of the unclear options? If you agree, I'll prepare a commit with these adjustments.

Regarding vcpkg, while it might be integrated later, I'd like to begin by refining the existing musl Docker setup.