First we only support header-only dependencies, any other kind of libraries have to disappear.

As a library author you want your library to be used easily.

The problem is that your users might get an hard time to consume your C++ library, if you do depend on some other library yourself.

Dependency management is hard in C++ because there are :

• so much target platform
• so much build systems (cmake, visual studio, scons, autotools, bjam, waf, gyp, gn, bazelbuild, ninja...)
• so much kind of users

Your library will be consumed by two different kind of users :

• The app developer that just copy/paste your code in his project
• The system builder which wants clean sysroot and good transitive CMake package dependency.

• No installation needed
• Relies on git
• Support non-#inglued <> deps as well by #include scanning
• Allows copy/paste of library in other project
• Generates CMake if wanted

Definitely not, this is only glue to ease the shipping of your header-only library. The goal of this tool is to hide dependencies to users who doesn't care.

It automates and ease the version upgrade of your dependencies, but application code author shouldn't bother, they will just reuse.

No, we give you access to any github.com repo which is the largest dependency store out there.

inglued cmake allows you to automagically generate a correct CMakeLists.txt for your lib but you don't have to. Read more about CMAKE Support

Here is a solution to provide your library easily to your users, without needing your users to install yet another tool.

• Either directly by copy/paste in user project
• Or integration via installation in sysroot
  • CMake Package Config for the CMake freaks
  • CMake build files for the system packager.

It simply provides you with a way to package dependencies inside your git repository.

And the best, is that it doesn't use the cumbersome submodules, but the marvelous subtree.

Users just need to include your library folder. The rest is done by you using #inglued <>.

1. Add a new file deps/inglued :

{
    "nlohmann/json"                   : { "@" : "v2.1.1", "-I" : "src/" }
  , "boostorg/preprocessor"           : { "@" : "boost-1.62.0", "-I" : "include/" }
  , "boostorg/fusion"                 : { "@" : "boost-1.62.0", "-I" : "include/" }
}

2. Run inglued seal, and 💥 you can tag your lib & let users download it via Github Releases.

Library example-dependency depends on :

• nlohmann/json
• Boost.Preprocessor
• Boost.Fusion

The users of example-dependency have to tediously install all these transitive dependencies and the other dependencies they also bring ?

We've created #inglued <> to solve this. 😉

• Dependencies ready in deps/inglued
• inglued seal : see diff
• inglued cmake header-only example-dependency example-dependency : see diff

Thanks to these three commands we satisfy :

• the user who doesn't care and just want to code :

  • He copy/paste your lib in it's project

• the user who wants to integrate your lib in it's sysroot :

  • He runs : cmake . && make install

• the user who wants to take it's own version of your dependencies

  • He runs : cmake . -DINGLUED=OFF && make install

See our ROADMAP

You don't bother as what this tool do will not have impact on your code, but in case : Boost Software License.

Please give copyright notice for this project if you find it good.

Copyright (c) 2017 Damien Buhl alias daminetreg ([email protected])

Give them copyrights too !

• Patrick Wieder ([email protected]) : linkineo