Summary: | [NEW PORT] textproc/libxml++50: XML API for C++ | ||||||
---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | John Hein <jcfyecrayz> | ||||
Component: | Individual Port(s) | Assignee: | Alexey Dokuchaev <danfe> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | danfe, diizzy, jailbird | ||||
Priority: | --- | Keywords: | feature | ||||
Version: | Latest | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
URL: | https://libxmlplusplus.github.io/libxmlplusplus | ||||||
See Also: | https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264700 | ||||||
Attachments: |
|
Description
John Hein
2022-06-16 00:27:46 UTC
Note that this does not conflict with libxml++26 If this is a dependency for resolving bug 264700, please add that issue here as a "Blocks". It can be removed if it turns out there's an alternate strategy/resolution (In reply to Kubilay Kocak from comment #2) "If this is a dependency for resolving bug 264700". Not necessarily. PORTVERSION --> DISTVERSION (Suggested by Porters Handbook) Add GNOME to MASTER_SITES (alias) libxml2 dependency should use USE_GNOME [1] Please soft USES in alphabetical order Why are we overriding upstream -std=c++17? Do we need a static lib? fwiw, BINARY_ALIAS is a one line patch (already fixed in upstream) https://github.com/libxmlplusplus/libxmlplusplus/blob/master/meson.build#L48 I'd rather see we fixing it here instead of adding workarounds PLIST_SUB, you can probably be a bit more create and use ${DISTVERSION:R}? You probably want to add options for building unit tests (which works so don't disable permanently) [1]: https://docs.freebsd.org/en/books/porters-handbook/book/#using-gnome Best regards, Daniel Since the name `textproc/libxml++' (port had been removed) is vacant, we should probably just resurrect it. I'll take it from here, thank you. *** Bug 264813 has been marked as a duplicate of this bug. *** A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=edda35495236e91396238b98d4993dbaa83aa7b7 commit edda35495236e91396238b98d4993dbaa83aa7b7 Author: Alexey Dokuchaev <danfe@FreeBSD.org> AuthorDate: 2022-06-28 11:32:34 +0000 Commit: Alexey Dokuchaev <danfe@FreeBSD.org> CommitDate: 2022-06-28 11:32:34 +0000 textproc/libxml++: resurrect^Wreadd the port and update to version 5.0.1 Keep the VERSION vs. API_VERSION separation for the time being to remain consistent with the `textproc/libxml++26' port. Install both static and shared libraries for the same reason. PR: 264699 MOVED | 1 - textproc/Makefile | 1 + textproc/libxml++/Makefile (new) | 21 ++++++++++ textproc/libxml++/distinfo (new) | 3 ++ textproc/libxml++/files/patch-libxml++.pc.in (new) | 8 ++++ textproc/libxml++/files/patch-meson.build (new) | 20 +++++++++ textproc/libxml++/pkg-descr (new) | 8 ++++ textproc/libxml++/pkg-plist (new) | 47 ++++++++++++++++++++++ 8 files changed, 108 insertions(+), 1 deletion(-) (In reply to Daniel Engberg from comment #4) > Add GNOME to MASTER_SITES (alias) > libxml2 dependency should use USE_GNOME These were taken from the resurrected port. > Why are we overriding upstream -std=c++17? Probably copied over from the `textproc/libxml++26' port, I did not commit those. It makes even less sense because the first user of this port, `www/elinks' requires `lang/spidermonkey78' and that needs C++17 because of the std::is_array_v (at least). > Do we need a static lib? Not sure, but I've kept it as to match the `textproc/libxml++26' port. We might revisit this later. > BINARY_ALIAS is a one line patch (already fixed in upstream) Nice catch, thank you, I've used that instead. > PLIST_SUB, you can probably [...] use ${DISTVERSION:R}? Absolutely. > You probably want to add options for building unit tests Looks like with meson, they got hooked to our ``make test'' automatically. Nice work! Shouldn't it also use https://github.com/freebsd/freebsd-ports/blob/main/Mk/Uses/compiler.mk#L10 ? (In reply to Daniel Engberg from comment #9) > Shouldn't it also use c++17-lang? Technically this won't hurt, but since our system compiler supports C++17 across the universe these days, it's actually a no-op. Previously it was required because we've been still with GCC 4.2 e.g. on PowerPC and MIPS, while on modern Clang everywhere else. |