sharkdp / dbg-macro

A dbg(…) macro for C++
MIT License
2.97k stars 257 forks source link

cmake export targets #130

Closed tomeichlersmith closed 8 months ago

tomeichlersmith commented 1 year ago

This resolves #83 .

What did I do?

I added the boilerplate CMake necessary to install the CMake packaging files alongside the dbg.h header when make install is invoked. This allows downstream packages to discover the dbg_macro package with a simple find_package(dbg_macro) call. I also added a Unix-only test that simply installs the the package (after it passes the local tests) and attempts to use the installed copy with the new tests/cmake project - simply re-compling the demo.cpp test if the package is found and linked successfully.

Big Warning

In order for the CMake target exporting to be functional, it has to be aware of the project version. Right now, I simply manually wrote the project version into the CMake file, but there are ways to use git to auto-deduce the project version [^ 1] in order to avoid having to define the version in two places (git and CMakeLists.txt).

[^1]: This basically amounts to a git execution during the CMake configure step. If you want, I can dig up my old CMake code on how to do this and integrate it.

Open Questions

tomeichlersmith commented 1 year ago

@sharkdp Your recent release of this package reminded me that I left this PR open. Is there something I should do to help get it merged or have you just not had time to try it out?

No rush on my end, just wondering if there is anything I can do to help.

sharkdp commented 1 year ago

@tomeichlersmith Sorry for leaving this hanging for so long. This looks good, actually. To be honest, I think I haven't looked further into it so far because it adds quite a lot of code/documentation and I wasn't sure if it's worth it. Are people really properly installing dbg_macro into their C++ projects?

tomeichlersmith commented 1 year ago

Good point - I can't speak for anyone else, but the use case I see is having a proper system installation for containerized development workflows. The projects I work on are mainly developed in a container whose image is shared amongst all our collaborators and so installing a dev tool like this into a system path findable by CMake would be helpful in that case so everyone can use it simply by updating the container image they are using.

That being said, with how light the dbg header is, using CMake's FetchContent also solves this problem of distributing the same tool to all of the developers.

I guess I don't have a strong opinion - this is your project and I just copied the CMake boilerplate I've used for other projects. Up to you! I guess I'd just suggest to close #83 either way to reflect that a decision has been made :slightly_smiling_face:

sharkdp commented 8 months ago

Thank you. I am going to close this for now and reconsider if someone else posts here or in #83, see my comment there.