| Git Clone URL: | https://aur.archlinux.org/cpp-httplib-compiled.git (read-only, click to copy) |
|---|---|
| Package Base: | cpp-httplib-compiled |
| Description: | A C++ HTTP/HTTPS server and client library (compiled version) |
| Upstream URL: | https://github.com/yhirose/cpp-httplib |
| Keywords: | networking requests |
| Licenses: | MIT |
| Conflicts: | cpp-httplib |
| Provides: | cpp-httplib, libhttplib.so |
| Submitter: | sum01 |
| Maintainer: | sum01 |
| Last Packager: | sum01 |
| Votes: | 3 |
| Popularity: | 0.000080 |
| First Submitted: | 2020-05-29 03:12 (UTC) |
| Last Updated: | 2024-02-06 17:56 (UTC) |
I looked into making it a split package, but since the header-only and compiled versions aren't using the same build I'm not sure it's worth doing. As far as I can tell, it would require anyone using the header-only package to still compile the whole thing, even though they don't need it.
Didn't realize having DESTDIR on the end vs front mattered, but I'll change that.
DESTDIR must be an environment variable to work with all cmake generators: DESTDIR="$pkgdir" cmake --build . --target install
You should make a split package to ease maintenance, because the source code and version are the same for both the header-only and compiled packages :p
Sorry, it's just me who finds the -compiled suffix ugly :p
Otherwise, could you add libhttplib.so to provides=() [1] and set CMAKE_BUILD_TYPE to None [2]? :D
[1] https://wiki.archlinux.org/title/Arch_package_guidelines#Package_relations
@abouvier I'm not sure there's much benefit to renaming it now. libhttplib also seems a bit redundant. I believe the pinned comment is enough to explain the differences between the two (as well as what I have in the description).
See the previous conversation I had with FabioLolix about there not really being any "standard" way to go about something like this.
And what do you think of the name libhttplib for the compiled version? :p
@sum01 Sorry I meant the public header interface of the library, not the full header-only library.
@abouvier yes that's how I was using it. I suppose it could make sense to require them all, at least for the compiled version.
As for having both in the same package cpp-httplib, I don't think that would work, as the Cmake files vary based on if it was header-only or compiled. I could have it install only the compiled version's cmake files, but there are minor differences between them regardless (namely, it's aware it's header-only).
Are you using the optdepends array as an "optmakedepends"? It's not working because users need to manually install the required libraries before building the package.
I think you should build the library with every option enabled. Or create multiple packages for every possible combination of options :p
And I vote for the cpp-httplib package containing headers and shared lib ;)
There are header-only packages in official with no -header suffix. Considering header-only is the default in upstream, and there's no real rule for this, I think I'll leave it as-is.
Pinned Comments
sum01 commented on 2021-04-23 19:40 (UTC)
@Spixmaster so
cpp-httplibis header-only, and must be compiled in any project you use it in.cpp-httplib-compiledsplits the header into an interface (header) and implementation, allowing you to just link against it. Lets you avoid having to compile it every time.