-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Publish the cross-compile toolchain as a container image #3
Publish the cross-compile toolchain as a container image #3
Comments
Please comment on whether this implementation meets your expectations for a cross-compile container image: https://github.com/openziti/ziti-tunnel-sdk-c-builder#readme. |
This solution will replace the Debian-based cross-build container documented in this repo's README file. |
@ekoby has suggested that we broaden the scope of the container image to be a more general-purpose build tool shared by the CI and local build scripts in the following projects:
I am beginning to investigate the build requirements for C-SDK and zitify since they may be different from T-SDK. I propose the follow developer experience for local builds for each project: A build.sh script in the repo will have the default behavior of emulating the CMake workflow in CI. Optionally, the developer may override the default build target, etc. by specifying arbitrary CMake options and arguments. As a stretch goal, the build script could detect the host arch of the developer's workstation and automatically compile for that target arch. Please comment on whether this would meet your expectations. Notably, I do not plan to design a CLI/API for the build procedure, i.e. replete opts and args for the developer to learn in order to interact with the build script. If this is an important goal for you then please comment on how you want that to work and why. |
This solution will replace some of the steps in this repo's CMake CI workflow. For example, the steps that install and run |
I would prefer that Docker image does not make assumptions about the build process or scripts. For example in CI, I just want to use this image like this
so I can still use github actions that provide useful utilities, like caching I guess I just want an image that has all the tools -- cmake, git, gcc, gcc-crosscompile, etc |
That makes sense. I'd like to propose the following solution summarizing the input I've received up to this point. Please comment on whether this meets your expectations for a CMake container image.
|
I have updated the README.md in this issue's resolving pull request to reflect the implementation sketch above. |
the prescription for cmake.sh seem superfluous in this context, the consumer project can do whatever, right? |
That's true. It's technically superfluous because the container image will not prescribe any command or use case, assuming the premeditated series of changes in the repositories that will consume this new container image are acceptable as described here. That assumption is probably correct. If that assumption is incorrect, and the consuming repos must use the image differently for some reason, then it will change the design of this image. |
I've marked the associated pull request ready for review. After acceptance of the initial design, I plan to test the automatically published image with each of the Ziti projects that could adopt this image in their CI. |
Here's an implementation of |
❯ ./cmake.sh help
Usage: cmake.sh [CMD] [ARGS...]
Runs CMD in the ziti-cmake container, and builds the
default target if no CMD is specified
-c CMAKE_CONFIG set CMAKE_BUILD_TYPE (default: Release)
-p CMAKE_PRESET set CMAKE_TOOLCHAIN_FILE preset (default: ci-linux-x64)
-t CMAKE_TARGET set CMAKE_TARGET (default: bundle) |
@scareything Will you react to the emulation experience on your M1 macOS? I've raised a new issue in this repo to improve the experience on arm64 silicon by running the build in an arm64 image instead of emulating amd64. |
The purpose of this change is to improve the developer experience for T-SDK, specifically building the
ziti-edge-tunnel
(ZET) binary. Building the C-SDK and ZET packages (RPM, DEB) are not in scope for this issue.The new container image will be versioned separately from T-SDK and live in a separate repo. It will be based on the unofficial cross-build container, which will be updated to use Ubuntu Bionic for GLIBC 2.27.
Then, a version of the new container image will be pinned to the CMake workflows for the T-SDK, replacing the current job-container,
ubuntu:18.04
(link to workflow).The text was updated successfully, but these errors were encountered: