Giters

uriparser / uriparser

:hocho: Strictly RFC 3986 compliant URI parsing and handling library written in C89; moved from SourceForge to GitHub

Home Page:https://uriparser.github.io/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CMake: Please introduce an option URIPARSER_SHARED_LIBS to allow fine-grained control over BUILD_SHARED_LIBS

alanbarr opened this issue · comments

commented

Hi,

I was recently looking at incorporating this project iinto another via using FetchContent.
However I ran into some problems with BUILD_SHARED_LIBS.

As this is a cache entry its global, and had the unfortunately effect of building everything else in the project as shared.
The build is currently mostly static libraries by default, with the third party libraries such as uriparser being the exception.

So, I was wondering what peoples thoughts would be on some changes to the cmake system to allow the library to be easily incorporated into a larger project?

I wouldn't be particularly comfortable with CMake, but skimming the file I think BUILD_SHARED_LIBS is the only thing which stands out to me. But I'm not entirely sure how to best manage that.

  • Only add it to the cache if uriparser is the top level project?
  • Juggle some URIPARSER_BUILD_SHARED_LIBS variable instead?

Regards,
Alan

commented

Hi @alanbarr,

if I understand your scenario correctly, you want to control whether uriparser is built as a shared or static library without forcing the same effect/decision on other CMake libraries in your larger build system.

For a quick workaround, you can probably backup-and-restore BUILD_SHARED_LIBS around the call to FetchContent.

For a less hacky mid-term solution, we can definitely introduce a new option URIPARSER_SHARED_LIBS for full control here. It would be similar to EXPAT_SHARED_LIBS in libexpat.

Best, Sebastian

commented

PS: Uriparser is using BUILD_SHARED_LIBS currently only because it's a default CMake thing.

commented

Thanks for considering the request.

For a quick workaround, you can probably backup-and-restore BUILD_SHARED_LIBS around the call to FetchContent.

That was definitely on the list of things to try.
I've had some success with using CMAKE_POLICY_DEFAULT_CMP0077 and setting BUILD_SHARED_LIBS as a "normal" variable prior to building uriparser. That seems to do as advertised and blocks the variable being added to the cache.

PS: Uriparser is using BUILD_SHARED_LIBS currently only because it's a default CMake thing.

Yeah, given that exists, I do wonder if we're doing something wrong by mixing and matching libraries...

commented

@alanbarr best news first: I have pull request #170 ready for review and testing now. Could you test it out?

That was definitely on the list of things to try. I've had some success with using CMAKE_POLICY_DEFAULT_CMP0077 and setting BUILD_SHARED_LIBS as a "normal" variable prior to building uriparser. That seems to do as advertised and blocks the variable being added to the cache.

Intersting that you mention CMP0077 (which requires CMake >=3.13). Related and potentially of interest:

We may need something like that in uriparser at some point, too.

Yeah, given that exists, I do wonder if we're doing something wrong by mixing and matching libraries...

I'm not fully sure I understand the term "mix and match" in this context (English not being my native language). You're wondering if it should all be static or all be shared but not a mix? (From a security point of view, all shared may be best if the system around receives security updates during its lifetime. Overlaps with https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies to some extent.)