Include google test using CMake integration

[jgsuess]

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 ?

[hartwork]

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?

[jgsuess]

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 gtests 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.

[jgsuess]

I am happy to contribute these changes if you would accept a patch. What do you think?

[hartwork]

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?

[jgsuess]

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 as externalProject.
• 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).

[hartwork]

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?

[jgsuess]

Hi Sebastian, Sorry for writing back this way, cannot be bothered to fiddle with 2FA on the bus. Generally, I agree with your point of view, but if you are using distro-based input, there should also be distro-based output. This means writing a docker ci loop and producing a package that is then provided say, via a ppa. Otherwise, you cannot be sure which version the distro actually provides, abd more importantly, if you link to underlying layers, you cannot be sure that your dependencies at runtime are available. You take in packages from a repo, you produce packages for a repo. In your case, probably a Ubuntu PPA. In this case, there should be a find package file for each distro that picks up what is required. It can be based on this: https://gitlab.kitware.com/cmake/community/wikis/doc/tutorials/How-To-Find-Libraries#user-content-piggybacking-on-pkg-config Your first case is the more elegant but harder one. The more common case is to source-build everything and use CMake as the vehicle. This is what ExternalProject does. It downloads the source of the version you require (and that softwarre, in turn might get its own dependent sources) and compiles and links with on-board tools. In /theory/ portable C++ can be written and every project can be ported this way. In practice, this can be more messy. However, if you do not want to control your build environment via docker and CI and do not want to provide output as packages, this is your ticket. As for windows, the approach that windows installer takes is that every package brings or downloads its own wad of DLLs. If they present, fine, otherwise they are installed at install time. There is a central registry, so you can look up. Cheers, JG

…

On Tue, 26 Mar 2019 at 02:27 Sebastian Pipping ***@***.***> wrote: 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 <https://packages.debian.org/buster/libgtest-dev> and Gentoo <https://packages.gentoo.org/packages/dev-cpp/gtest> — 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? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAvxkQPtVIdjlZ3jIEf5G9qdv3iwERWsks5vaPj8gaJpZM4b4uwA> .

[hartwork]

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

[hartwork]

Looks like this ticket is no longer relevant. Happy to re-open anytime. Closing.

[jgsuess]

Yes, thanks Sebastian. I had to use a different library as I could not work around this. :(

…

On Mon, 13 May 2019 at 05:31, Sebastian Pipping ***@***.***> wrote: Looks like this ticket is no longer relevant. Happy to re-open anytime. Closing. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#58 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAF7DEN32K3ZVJ47525DNG3PVBWCVANCNFSM4G7C5QAA> .

-- 730 Hawkesbury Road Anstead, QLD 4070 Australia email: jgsuess@gmail.com