Include google test using CMake integration
jgsuess opened this issue · comments
Currently, google test is acquired using the travis build environment. This means that the source
component cannot be transparently incorporated into other source builds. The gtest team recommends the following integration method, which removes this issue:
Incorporating Gtest Into An Existing CMake Project.
Would it be possible to use this mechanism in uriparser
?
I consider bundling code more of a problem than a solution for a number of reasons. Since uriparser is hardly used in isolation, I don't see strong need for bundling for convenience so far. Am I missing a certain scenario?
I am not addvocating bundling the code. The recommendation is to use externalProject
in combination with a git hash and find_module
. This will include no code, but will allow a source integrated build that is module-based. This allows the library to be built without explicit platform binary dependencies.
If tip tracking is your objection, you can set the link to be master
and trigger rebuilds on every Google Test upstream change. This way, you will never miss any developments good or bad. You can have a separate branch where you peg the release you want to be stably used and update to new releases when convenient.
Also, looking at the discussion you have linked, the clause below is true for uriparser
: When uriparser
is built, the gtest
s are statically linked to the framework. As per definition:
In other words, code bundling occurs whenever your program or library ends up containing code that doesn't belong to it.
However, if you are taking the discussion's argument, then uriparser
should be package managed as a consequence: It should be a source package with a descriptor that enumerates the link libraries it requires for building, the build system and the compiler required to build it. Gentoo does that very well.
I am happy to contribute these changes if you would accept a patch. What do you think?
Hi!
Interesting! Comparing an in-git bundle to an external SHA1 my impression is that both of them would go stale and need updating so that these seem like to flavours of the same thing to me. The master
case you mention is different.
Inside the CI, using a pinned version of gtest seems best to me to not put build stability at risk. So if we went this route, I guess we'd need pinned for CI and master
else. Maybe a switch to get users back to the pinned version if gtest master
is broken.
Before you start building patches, can you elaborate on what we are trying to improve on? If uriparser is not in a vacuum with you, what's around it and why would uriparser building gtest help your case? Is gtest the only other dependency you need to build? What if two libraries both reference-include gtest and you build two copies in the end?
Before you start building patches, can you elaborate on what we are trying to improve on?
- We want to ensure that it is easy to reuse
uriparser
. Either it is a package and installs with dependencies, or it is a CMake source and installs asexternalProject
. - Is gtest the only other dependency you need to build?
No, I would assume that uriparser would build other libraries in so far they expose as a quality cmake project. Even if they do not (i.e. they are automake or something else) , I would probably build them using externalproject.
What if two libraries both reference-include gtest and you build two copies in the end? - Completely possible and normal. The export rules described in cmake control what you include for linking. It is hardly ever possible to do version canonisation on large projects. (compare maven enforcer canonization rule in Java world and check how often that is actually used).
Hi Jörn, I'm still thinking about this whole thing.
By now It has come to my attention that gtest is not a "classic" runtime — but a test/buildtime — dependency and hence produces less of a bundling problem than "true" runtime dependencies. Hardcoding a SHA1 of gtest 1.8.1 might actually be fine, as a consequence.
Linux distros have recent gtest packaged — see Debian and Gentoo — and I'd consider using the distro package during compilation the "right" way for users of those distributions. There should at least be a way to build against those packages, maybe even by default, in my world.
I'm unsure how standard use of a package manager for development has become on Windows.
I'm in for making things easier on Windows if things remain "sane" for Linux.
What do you think? Is this about specific platforms more than others?
Hi Jörn,
I'm having trouble following your assessment. Let's start fresh based on szenarios so that we're on the same page, okay? For use of uriparser, I can think of these szenarios:
- (a) Use by an application/library as a third-pary dependency with bundling (code copied or
ExternalProject
) - (b) Use by an application/library as a third-pary dependency without bundling
- (c) Use by a user who needs a more recent version that his/her distro provides
- (d) Use by a user who tries to build a project of type (b) to fulfill its dependencies
- (e) Use by a package developer to package uriparser for a distro
What effect is to be expected by use of ExternalProject
on these cases? I think:
- For (a) it would be a bit less work and less control
- For (b) it has no effect
- For (c) and (d) potentially easier to use if the user intends to run tests prior to installation; would save a "gtest not found" error and figuring out what to do
- For (e) it would be trouble (due to off-distro dependencies and build time internet access) and need a bypass option. Forcing downstream to patch it away would not be an option to me.
Your szenario at Oracle is (a) I suppose — is that correct?
If we get a switch to bypass ExternalProject
altogether for (e), I'd be okay with it's use by default.
PS: Regarding find modules / discovery of uriparser:
- uriparser continues to generate a pkg-config file
- uriparser comes with a config module but cannot do much about the find module: That file would need to be provided by CMake or be shipped by projects using uriparser. For uriparser >=0.9.2,
find_package
can be used as documented at https://github.com/uriparser/uriparser#example-use-from-an-existing-cmake-project .
Looking forward to your reply!
Best, Sebastian
Looks like this ticket is no longer relevant. Happy to re-open anytime. Closing.