How to manage utility modules and code snippets with git, boost, [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

When programming I accumulate code snippets and utility classes. I want to store those for practical future use.

The question briefly is what is the best way to do this. More elaborate with an example:开发者_StackOverflow中文版

When writing code we keep reusing our nice tidbits to cover common tasks. However in order to make our projects open source, say with git on github, this tidbits also need to be available. I was wondering how to best do this.

• Do I make my personal utilities repo that projects can add as submodules in git?
• Or do I make separate git repos for each tidbit, so a project can add a specific version of a specific tidbit as a submodule. (this addresses a problem with utility libraries like boost, which get huge even though your program might only need a small portion of it)
• Or do I combine both into a a utility repo with submodules where the external projects can have the utility repo as a submodule? What happens if they want to use version x of tidbit a and version y of tidbit b? Could be nice just to have a centralized overview?

Like all public code, snippets like that should be light, fast, tested, portable, documented and preferably relatively self contained. Now I find this nice code somewhere and it uses CTASSERT, which is not portable.

What should I do?

• I can use boost static_assert, but that adds a major dependency to a little code snippet, because boost is not trivial, and on my system it compiles to about 2GB. To make things worse, it also adds this dependency to every project using the snippet which provides some quite basic functionality. Further, boost as far as I know has no git repo, so a project can not automatically take care of this dependencies with a submodule.
• Do I make another snippet and pull my own compile time assert with the silly side-effect of reinventing the wheel and creating more code doing things that boost already does.

Im looking forward to hearing how you solve this problem, and general thoughts and guidelines.

---

There seems to be little animo in this, but I am still really quite excited about it and hoping for input ideas from others. This is what I have come up with:

Motivation

Every programmer accumulates a bunch of reusable code snippets. Most often however these snippets end up in a global header file for a project from where they are then copy/pasted to new projects.

This has a few disadvantages. The code is clumsy and it is denied it's own life with proper unit testing and development evolution. Further this leads to several copies of similar or identical code lingering around without infrastructure to maintain them at once.

Any publicly released code also needs the code snippets to be up to standards and thoroughly tested.

Implementation

I found that a good solution for this can be created with a snippet library in git. All future projects I create can just take in this library as a submodule and individual snippets are again submodules from that repo. The user can than choose to only download those snippets they use while enjoying a central include directory for all, and central access to documentation and unit testing.

I have one TidBits_Cpp repository. This repository has submodules with each code snippet.

The main repo has an include directory just like boost, except that the includes in the central directory only include other files from subdirectories and there is only one exactly per tidbit, the one include you need if you want to use that tidbit. They wrap the subdirectory includes in a namespace tidbits. Keeping the namespace outs of the submodules allows other people to include these snippets in their own snippet libraries and add their own namespace around them.

Each submodule with a snippet has mainly header only implementation with a header for unit testing, and a standalone unit testing app.

The unit testing base class is also a TidBit. The main repo has a unit testing application that tests all the TidBits that exist on the system. For this it has a directory with dummy includes which should be last in the include path, so you can always compile. Checking defines allows to know which code is actually available for unit testing.

All code in the submodules assumes the central include directory to be in the include path.

Included in the repository are DoxyFiles, as well as visual studio solutions. Eclipse is harder because it deals badly with projects that use cpp files from different directories. I will add MakeFiles later for other compilers and platforms.

To get the full power of this any project that wants to use a TidBit should include a submodule pointing to the main TidBits_Cpp repository, and then pull the submodules they want to use. They can immediately run all unit tests without writing any code, and then just start coding.

The overhead from the parent repo is small, since it only contains one-line includes as well as 1 folder with some unit testing stuff and a DoxyFile.

The beauty of this kind of system is that the snippet repos need not even by my own. I can call in any github repository as a submodule, and so can other

Considering the static assert, well, I did pull my own one, although there are solutions available here without having to add boost as a dependency for a code snippet. The main reasons I would not do this is because boost is big and it is not available as a git repository, so it cannot get downloaded automatically as a submodule.

However, as Georg Fritzsche pointed out here it is possible to extract a part from boost with bpc. The disadvantage is that for static assert for example this still means 70 files...

If you are interested, this is the link to my repository, however consider it at the moment not more than an illustration to this post. The code in there right now is still very much under development and not yet suited for public release. Neither is there documentation etc. All that is for future times.