3 ms·

> Include <structopt/app.hpp> and you're good to go. I haven't touched C++ for almost a decade but I assume there's (still?) no obvious way that always works t

> Include <structopt/app.hpp> and you're good to go. I haven't touched C++ for almost a decade but I assume there's (still?) no obvious way that always works to include a dependency package in your build? For you C++ devs, does this instruction make it obvious how to install this thing into your project?

nestorD 6y ago
The instruction makes me suspect that it is a header only library. In this case I would just drop the library source in a dedicated subfolder and expect it to work. (While it feels better than fighting the system to get a dependency to link properly I would still rather have a proper package manager...)
flohofwoe 6y ago
It requires some digging into the project, because at first glance it doesn't seem to be a simple header-only library. There's a conanfile.py, and a CMakeLists.txt and all sorts of "junk" in the project directory. But in the end it all seems to come down to this single header file which only depends on C++ stdlib headers and which can be dropped into your own project (which seems to be generated (aka "amalgamated") from multiple smaller header files): https://github.com/p-ranav/structopt/tree/master/single_include/structopt https://github.com/p-ranav/structopt/tree/master/single_incl... So for typical C++ libraries, this seems quite straightforward to integrate. Usually when looking at a project directory full of random files like this, it's a lot more complicated.
f00zz 6y ago
If your project uses CMake, you could * add the structopt repository as a git submodule to your project * add something like `add_subdirectory(structopt)` to your top-level CMake script * add structopt to your target_link_libraries and you're good to go.
- skrebbel 6y ago
  You could do that if you wanted to use git submodules as a sort of poor man's package manager. But given that it's a header-only library, you can also just download the files, put them in your repo somewhere, and #include them.
- chrisdalke 6y ago
  If this is something you do in CMake projects, check out FetchContent_Declare — newer CMake versions have this command which downloads a git repository and caches it. I much prefer this to manually downloading the files, even for header-only libraries. The command provided a nice declarative way of adding a dependency.
  - f00zz 6y ago
    Thanks!
plq 6y ago
It mostly depends on how tight you want the coupling between your project and the dependency in question. It can vary between just getting the source files and building them yourself, just like you do with your own stuff, to just using the public headers plus the relevant static/shared library. Most of the time, you'll want the latter. The right thing to do in 2020 in that case is IMHO to integrate with a source-based build system like vcpkg, portage (see the prefix project), conan, macports etc. Once the dev-env setup script boils down to just a list of packages, the question of importing third-party dependencies stops being a pain. I've used most of these (except conan) and vcpkg seems like it's the most painless one, especially because it's a CMake-based system and FWIW CMake seems to be what the C++ world is converging on these days. From my bubble anyway.
beached_whale 6y ago
During, I think MS Build, Microsoft said, vcpkg, it's their C++ package manager, will support this this year. I read it on their roadmap file in the repo too. VCPKG seems to be the path of least resistance, works accross platforms too
CyberDildonics 6y ago
If you have a single source file with no dependencies you can just include it into whatever compilation units you want. That is very easy and elegant. When there are complex dependencies it becomes more problematic.
snarfy 6y ago
My previous employer's binary repository settled on using nuget for everything as it was primarily a .NET shop. For our internal C++ projects I made a 'nuget_package_add' CMake script which allowed us to package a lot of our C++ libraries and use them by adding a single line to our CMake scripts. The main problem was nuget support for C++ DLLs is pretty horrible. I did not want to resort to parsing the .targets file from CMake script so I ended up making non-standard nuget packages that pretty much only worked with our CMake script.

nestorD 6y ago

The instruction makes me suspect that it is a header only library. In this case I would just drop the library source in a dedicated subfolder and expect it to work. (While it feels better than fighting the system to get a dependency to link properly I would still rather have a proper package manager...)

flohofwoe 6y ago

It requires some digging into the project, because at first glance it doesn't seem to be a simple header-only library. There's a conanfile.py, and a CMakeLists.txt and all sorts of "junk" in the project directory. But in the end it all seems to come down to this single header file which only depends on C++ stdlib headers and which can be dropped into your own project (which seems to be generated (aka "amalgamated") from multiple smaller header files): https://github.com/p-ranav/structopt/tree/master/single_include/structopt https://github.com/p-ranav/structopt/tree/master/single_incl... So for typical C++ libraries, this seems quite straightforward to integrate. Usually when looking at a project directory full of random files like this, it's a lot more complicated.

f00zz 6y ago

If your project uses CMake, you could * add the structopt repository as a git submodule to your project * add something like `add_subdirectory(structopt)` to your top-level CMake script * add structopt to your target_link_libraries and you're good to go.

skrebbel 6y ago
You could do that if you wanted to use git submodules as a sort of poor man's package manager. But given that it's a header-only library, you can also just download the files, put them in your repo somewhere, and #include them.
chrisdalke 6y ago
If this is something you do in CMake projects, check out FetchContent_Declare — newer CMake versions have this command which downloads a git repository and caches it. I much prefer this to manually downloading the files, even for header-only libraries. The command provided a nice declarative way of adding a dependency.
- f00zz 6y ago
  Thanks!

plq 6y ago

It mostly depends on how tight you want the coupling between your project and the dependency in question. It can vary between just getting the source files and building them yourself, just like you do with your own stuff, to just using the public headers plus the relevant static/shared library. Most of the time, you'll want the latter. The right thing to do in 2020 in that case is IMHO to integrate with a source-based build system like vcpkg, portage (see the prefix project), conan, macports etc. Once the dev-env setup script boils down to just a list of packages, the question of importing third-party dependencies stops being a pain. I've used most of these (except conan) and vcpkg seems like it's the most painless one, especially because it's a CMake-based system and FWIW CMake seems to be what the C++ world is converging on these days. From my bubble anyway.

beached_whale 6y ago

During, I think MS Build, Microsoft said, vcpkg, it's their C++ package manager, will support this this year. I read it on their roadmap file in the repo too. VCPKG seems to be the path of least resistance, works accross platforms too

CyberDildonics 6y ago

If you have a single source file with no dependencies you can just include it into whatever compilation units you want. That is very easy and elegant. When there are complex dependencies it becomes more problematic.

snarfy 6y ago

My previous employer's binary repository settled on using nuget for everything as it was primarily a .NET shop. For our internal C++ projects I made a 'nuget_package_add' CMake script which allowed us to package a lot of our C++ libraries and use them by adding a single line to our CMake scripts. The main problem was nuget support for C++ DLLs is pretty horrible. I did not want to resort to parsing the .targets file from CMake script so I ended up making non-standard nuget packages that pretty much only worked with our CMake script.