DEV Community

ElshadHu
ElshadHu

Posted on

First Release to My CLI Tool

#cli #cicd #tooling #showdev

The Beginning: "How Hard Could It Be?"

After successfully building my RepositoryContextPackager tool with CMake and getting CI/CD working across Windows, macOS, and Linux, I thought, it is going to be smoother experience. At the end of the day I did my release to my RepoContextPackager, but the path to get there was much harder than expected. Looking back, I should have stuck with purely making Releases on my repo from the start.

The Initial Setup

I started by creating custom overlay ports for vcpkg. The structure seemed straightforward:

ports/
└── repositorycontextpackager/
     ├── portfile.cmake
     └── vcpkg.json
Enter fullscreen mode Exit fullscreen mode

The SHA512

Every time I made a commit and created a new tag, I had to update the REF in portfile.cmake, set SHA512 0 as a placeholder, then run ./vcpkg install repositorycontextpackager --overlay-ports=ports and wait for it to fail so I could copy the real SHA512 from the error message, update the portfile with the correct hash, and try again. I did this countless times. Even after changing the SHA key, vcpkg gave cryptic fetch content errors.

The Dependency Nightmare

My project used:

  • System libgit2 (via Homebrew/pkg-config)
  • tomlplusplus
  • GTest

But vcpkg wanted everything through vcpkg. Mixing them caused linking errors.I also had to use git pull origin main --no-rebase because of direct changes to main. I realized, allowing changes to main branch was really a bad idea, I should not have allowed that. Because even though, code works I will end up destroying git history in the repo.

The Change

After endless hours fighting:

  • Fetch content errors
  • Linking errors
  • SHA512 checksums
  • Breaking and fixing the build repeatedly

I gave up on vcpkg.I reverted to my simple CMakeLists.txt to make my life easier, I realized, using packager in C++ and handling all these dependencies will not happen in one sitting. I built release binaries for Windows and macOS, and my friend tested the macOS build: "It works perfectly." Everything ran as expected. Also, I originally used install(TARGETS repoctx RUNTIME DESTINATION bin) which explicitly tells CMake that the target is a runtime executable and should go in the bin directory. However, I switched to the simpler install(TARGETS repoctx DESTINATION bin) which lets CMake automatically determine the artifact type (executable, library, etc.) and handle it appropriately. This simpler approach proved more portable across different build systems and worked perfectly when my friend tested it on macOS

Don't Mix Dependency Sources

While doing this project in C++ I came up to the solution that it is better to choose one package and not mix with others.As a result of it, I decided to choose dependency strategy in the early stages of my next projects. Also, I need to document build process properly.

Gained Knowledge

After all of this, I realized that it's better to allocate extra time for tasks such as releases in order to avoid burnout. In projects, especially those related to configuration decisions, choices have to be made carefully at the start.

Top comments (0)