LennahSSG VS conan

This week we got the chance to learn how to package and release our SSGs. For my release I decided to use conan as my package manager and GitLab as my package repository. In order to make my package I had to do a few steps first, I needed to install conan and cmake so I could run the commands. I already had cmake installed from testing Andrew's SSG so that was nice. Then I had to make a new GitLab account and link it to my GitHub account so I could import my repo over to GitLab.

Homepage prototype

After I tested everything I was able to do an interactive rebase in Git to merge all my commits together. This was a really neat feature that allowed me to keep my actions/changes organized and it was super easy to do! If you want to take a look at my rebased commit you can find it here. While it looks like a lot was changed it was a lot more manageable because in reality it was a bunch of separate changes. This feature is great to make the commit history look a lot cleaner because I know I am someone who always tends to miss a few things here and there so the tiny commits tend to pile up. Now I don't have to feel as bad when I notice a small thing that needs changing, I can just rebase the commits!

This week, I focused on adding a new feature to my friends site generator, LENNAH SSG. Using a fork of his project with an issue branch, I was able to add support for config files using --config. I also created a draft pull request in order to better communicate our ideas to each other.

Last week when merging my partner's repo we encountered an issue where several files were in conflict. We opted to delete the conflicting files on his end to allow the merge, rather than going through line by line and seeing what was different and he kept backups so as to reintroduce any code that was cut if he so chose.

I decided the two features I wanted to add were things related to the markdown functionality of my SSG. I added support for inline code using the ` syntax and I also added support for the horizontal rule "---" syntax. Thanks to my classmate Gus, it was really easy to augment the existing code to add new features to the markdown support. All I had to do was add some if statements in the markdown handler section of the file reader to check for ` and --- then I just needed to add a new function for inline code generation. You can find the changes for the inline code implementation here and the horizontal rule implementation here.

When Gus made a pull request for my SSG, I found a few things I wanted him to change. First I wanted him to do the same thing as I did for his SSG; make the txt title/header functionality only work for txt files. Second, I noticed that he had if statements like this:

This week I worked on Joshua Li's SSG, LennahSSG again. I added support for markdown files, with the ability to distinguish and generate appropriate HTML tags for bold and italics.

The hardest part of testing/reviewing Joshua's code was finding anything to critique, it was that good. Like when a prof gives you code to work on, logically organized, concise and without mistakes. His code wouldn't compile using g++ originally, but after ignoring the warnings that came up it compiled fine. I think it was just a case of the compiler being finicky, it wasn't liking the multiple declarations of having prototypes earlier in the file but it ran fine after I ignored those. He also included an executable so it wouldn't have made much of a difference regardless.

It was also very nice to have someone else take a look at your code, I made a few silly mistakes that I would probably never have caught because it made sense in my head, such as my versioning being wrong. (Issue).

Conan is a package manager for C/C++. See: https://conan.io/.

The way it works is that you can provide "recipes", which are Python scripts, that automate the process of collecting source code (usually from a remote Git repository, or a remote source tarball), patching it, making its dependencies and transitive dependencies available, building for specific platform and architecture (via any number of build systems), then packaging up and serving binaries. There's a lot of complexity involved.

Here are the two recipes I mentioned:

libcurl: https://github.com/conan-io/conan-center-index/blob/master/r...

OpenSSL v3: https://github.com/conan-io/conan-center-index/blob/master/r...

Now, for the sake of this thread I want to highlight three things here:

- Conan recipes are usually made by people unaffiliated with the libraries they're packaging;

- The recipes are fully Turing-complete, do a lot of work, have their own bugs - therefore they should really be treated as software comonents themselves, for the purpose of OSS clearing/supply chain verification, except as far as I know, nobody does it;

- The recipes can, and do, patch source code and build scripts. There's supporting infrastruture for this built into Conan, and of course one can also do it by brute-force search and replace. See e.g. ZLib recipe that does it both at the same time:

https://github.com/conan-io/conan-center-index/blob/7b0ac710... -- `_patch_sources` does both direct search-and-replace in source files, and applies the patches from https://github.com/conan-io/conan-center-index/tree/master/r....

Now, good luck keeping track of what's going on there.

There were various approaches recommended depending on our language and ecosystem. My classmates who developed using Node.js were recommended npm, and PyPI or poetry for Python. Since my program is written in C++, I was recommended to look into one of vcpkg or conan, but I ultimately did not use either package manager.

Hi u/instinkt900, Conan maintainer here. Thanks for your feedback! Please remember that we actively monitor and respond to our issue tracker on GitHub (https://github.com/conan-io/conan/issues/new/choose), we’d love to hear about your specific use cases or pain points, so that we can improve your experience and that of other users. The motivation behind most of the updates in Conan 2.0 was precisely feedback from the community, and to improve our ability to continue delivering features in the constantly changing C++ ecosystem. We can certainly do this at a quicker pace, with some exciting new features recently released and in the pipeline: package metadata, transparent backup of downloaded package sources, cache least-recently-used cleanup, etc. A lot of the big decisions that we took for Conan 2.0 were taken with consensus from expert users and contributors (https://conan.io/tribe) and https://github.com/conan-io/tribe. Some specific workflows may not have 1:1 replacements in Conan 2.0, and are likely to affect some of the “less travelled roads” of Conan 1.x, including some features that were always marked as experimental. We are happy to hear feedback so that we can best satisfy these use cases. Conan 2.0 also includes a more sophisticated API to cover cases where the built-in integrations may not satisfy users needs. For what it’s worth - we have also heard very positive feedback from users about how Conan 2.0 simplifies their workflows when compared to Conan 1.x. The C++ tooling ecosystem is fragmented and moves at different speeds, including our users. So it’s always a fine balancing act, but we don’t want to leave anyone behind! An example is Conan Center - over 90% (~1200) of all recipes have been migrated to support Conan 2.0, while still maintaining compatibility with Conan 1.x, precisely to avoid breaking users that are still on Conan 1.x.

Solution: don't use git submodules - use a package manager like Conan or vcpkg.

The closest thing we have at the moment is conan[1]. It’s a cross platform package manager that attempts to implement “toolchains”, whereby different build systems can be integrated[2]. This is a big problem with package management in C/C++, there’s no single, standardised build system that most projects use. There isn’t even a standardised compiler! So when hosting your own packages using Conan, often you need to make sure you build your application for three different compilers, for three different platforms. Sometimes (for modern MacOS) also for two different architectures each.

If you control the compiler AND build system you can get away with just one package for most cases. This true for Microsoft’s C/C++ package manager, NuGet[3]

Historically, the convention has been to use the package manager of the underlying system to install packages, as there are so many different build configurations to worry about when packaging the libraries. The other advantage of using the system package manager is that dependencies (shared libraries) that are common can be shared between many applications, saving space.

[1] https://conan.io/

Anyway, the problems are today starting to get fewer, as more an more adopt standard cross-platform portable build systems, a.k.a. CMake and package managers such as vcpkg or Conan. Together this will take care of building, installing, linking and using the entire dependency tree.

Simply use a package manager: Crypto++ is available on both vcpkg and Conan.

If you want a specific version or provide a more integrated workflow that is easier to use across platforms and among many developers, use a package manager like vcpkg or Conan.

I do however always recommend using a package manager: vcpkg or Conan to install and integrate third party libraries (together with CMake). This normally solves all the typical problems with dependencies.

There's a few, look into Conan or vcpkg (the latter is my personal recommendation).