search

yet-another-user / pimpl

The C++ Pimpl Idiom Again!
36 stars 7 forks source link

added initial cmakelists.txt file. #17

Open madmongo1 opened 7 years ago

madmongo1 commented 7 years ago

Adds support for the CMake build manager.

Also adds [optional] support for the hunter dependency manager which is fast becoming the de-facto standard for seamless cross-platform management of dependant libraries.

after pulling, you can build the tests with

mkdir build cd build cmake make

muggenhor commented 7 years ago

I'll look at Hunter during the next week, because the problem that you mention, easy pulling of external dependencies, is one that I would very much like to see be less of a problem.

madmongo1 commented 7 years ago

cmake is already pretty good at producing both cmake packages and pkg.config outputs.

On 10 September 2017 at 16:59, Giel van Schijndel notifications@github.com wrote:

@muggenhor commented on this pull request.

In test/sugar.cmake https://github.com/yet-another-user/pimpl/pull/17#discussion_r137951576:

@@ -0,0 +1,12 @@ +sugar_files(TEST_SOURCES

From your description I get the impression that Hunter, while it uses CMake, is in practice a completely different build system that isn't interchangeable with plain CMake. I had hoped it would be able to just, at CMake-generation-time, walk all targets, extract its properties, and use those to produce an exportable "package". If it requires interfacing with CMake through it's own abstraction layer that seems rather unfortunate because that's a very invasive approach.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yet-another-user/pimpl/pull/17#discussion_r137951576, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7syfgjwabhHEOrwsEkT4rtmanuL-s6ks5sg_lVgaJpZM4PR_lR .

yet-another-user commented 7 years ago

Guys, have you come to an agreement regarding this pull request? I do not use/know cmake so I'll go with what you think is best. There seems to be a branch conflict also to resolve...

madmongo1 commented 7 years ago

I'm waiting for feedback but am happy to make is more vanilla in the meantime. I'll create a new pull request when I get a moment - I'm a bit under the cosh at the moment as I have a production release in 4 days.

On 15 September 2017 at 23:09, Mike notifications@github.com wrote:

Guys, have you come to an agreement regarding this pull request? I do not use/know cmake so I'll go with what you think is best. There seems to be a branch conflict also to resolve...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yet-another-user/pimpl/pull/17#issuecomment-329903264, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7syVdh30BeSW4d-dFnqLvl41ASqr_wks5siueHgaJpZM4PR_lR .

yet-another-user commented 7 years ago

Nice. Much appreciated. Maybe you, guys, might agree on and incorporate as big as possible a non-controversial bit; then maybe have the debatable bit as a separate file (like #include). That way you get the functionality you consider important but then it's not "in their face" for others. Just a suggestion... And certainly no rush... I was not sure where you, guys, were on the topic. So, I pinged.

P.S. I mentioned Hunter to our cmake guy... briefly. He said he considered and evaluated it a couple years ago; it left him cold... Don't shoot the messenger. :-) I'll keep you posted when I hear more.

On Sat, Sep 16, 2017 at 7:34 AM, Richard Hodges notifications@github.com wrote:

I'm waiting for feedback but am happy to make is more vanilla in the meantime. I'll create a new pull request when I get a moment - I'm a bit under the cosh at the moment as I have a production release in 4 days.

madmongo1 commented 7 years ago

Hunter is a lot more comprehensive now.

I cross-compile for iOS, Android, windows, linux and OSX. I have to write no special code in my cmake files, and don’t have to build and maintain dependent libraries. It’s all automatic.

Try doing that in cmake without hunter and polly.

But horses for courses :)

R

On 16 Sep 2017, at 00:01, Mike notifications@github.com wrote:

Nice. Much appreciated. Maybe you, guys, might agree on and incorporate as big as possible a non-controversial bit; then maybe have the debatable bit as a separate file (like #include). That way you get the functionality you consider important but then it's not "in their face" for others. Just a suggestion... And certainly no rush... I was not sure where you, guys, were on the topic. So, I pinged.

P.S. I mentioned Hunter to our cmake guy... briefly. He said he considered and evaluated it a couple years ago; it left him cold... Don't shoot the messenger. :-) I'll keep you posted when I hear more.

On Sat, Sep 16, 2017 at 7:34 AM, Richard Hodges notifications@github.com wrote:

I'm waiting for feedback but am happy to make is more vanilla in the meantime. I'll create a new pull request when I get a moment - I'm a bit under the cosh at the moment as I have a production release in 4 days.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/yet-another-user/pimpl/pull/17#issuecomment-329914616, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7sySlip0wYtraYjR50Ik9Mo-6Du8Xiks5sivPXgaJpZM4PR_lR.

muggenhor commented 7 years ago

@madmongo1 I rebased this branch on my plain CMakeLists.txt in this branch: madmongo1/pull-cmake.

After looking for a bit I do see some value in the Hunter portion, especially the virtualenv-like behaviour may be relevant here. The Sugar part of it doesn't seem to add any value over plain CMake however.

So if you agree, could you rebase your Hunter support (without the Sugar part) on top of latest master then we can get that in?

PS excuse the delayed reply, I've been doing (or trying to) way too much things at the same time lately.

muggenhor commented 7 years ago

Looking a bit more at Sugar I'm not clear what problem it's trying to solve, but it looks like it has some overlap with https://github.com/tomtom-international/cpp-dependencies. The latter has the advantage of not being necessary while building, only while running this tool after having added/removed a source file. It's even possible to automate this such that it's only necessary to execute this in CI (if you give these CI systems commit/push access).

muggenhor commented 7 years ago

I've just been at Meeting C++ where this, build systems and dependency management, are pretty hot topics. I've discussed this with a few people here (mostly Mathieu Ropert and Diego Rodriguez-Losada) and I believe the main problem with this approach is that it confuses the build system and package management. Dependency fetching is part of package management, not of building. That being said: dependency and package management are necessary, confusing the two just makes solving this more harder though.

I've been pointed at Conan, I haven't yet had the time to look at it, but from what I've been told it may solve this problem in a better way because it keeps package management split out from the build system and instead better integrates the two. Requirements can be specified in a similar format to Python's requirements.txt in a conanfile.txt. I'm not sure how usable this really is at this time, I have to look into that. It seems promising at least.

madmongo1 commented 7 years ago

If it’s properly cross-compiling-aware I think it’s worth a look.

On Sat, 11 Nov 2017 at 23:22, Giel van Schijndel notifications@github.com wrote:

I've just been at Meeting C++ where this, build systems and dependency management, are pretty hot topics. I've discussed this with a few people here (mostly Mathieu Ropert and Diego Rodriguez-Losada) and I believe the main problem with this approach is that it confuses the build system and package management. Dependency fetching is part of package management, not of building. That being said: dependency and package management are necessary, confusing the two just makes solving this more harder though.

I've been pointed at Conan https://www.conan.io/, I haven't yet had the time to look at it, but from what I've been told it may solve this problem in a better way because it keeps package management split out from the build system and instead better integrates the two. Requirements can be specified in a similar format to Python's requirements.txt in a conanfile.txt http://docs.conan.io/en/latest/reference/conanfile_txt.html. I'm not sure how usable this really is at this time, I have to look into that. It seems promising at least.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/yet-another-user/pimpl/pull/17#issuecomment-343698156, or mute the thread https://github.com/notifications/unsubscribe-auth/AE7sycH9wEA2EmgNJNg6LSSdf56pGjxqks5s1h4cgaJpZM4PR_lR .