https://bugzilla.redhat.com/show_bug.cgi?id=2412239
--- Comment #3 from Ben Beasley <[email protected]> --- (In reply to Terje Rosten from comment #2) > Summary: > ======== > - should package be called utest or utest.h? Looking at README.md, upstream seems to use the names "utest.h" and "UTest" interchangeably. So the ".h" doesn’t seem to be an essential part of the name. (If the header were also "UTest.h", one might make a case that lower-case naming was inappropriate, and the package should be UTest, but that’s not the case.) I note that “The maintainer MUST NOT use an underscore _, a plus +, or a period . as a delimiter” in package names, https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#_separators, so "utest.h" would not be a good package name, and there are no extant packages in Fedora named <something>.h. There is only one package, sandia-omega-h, that is named that way but with the period converted to a hyphen. The only reason to consider something like utest-h would be if there were another somewhat prominent piece of software with the "utest" name, but a quick web search didn’t turn anything up. I think I still stand by utest as the most sensible name. > - there in no pkgconfig or cmake integration, maybe ask upstream > to provide this? I’m not sure this is very necessary for a single-header, header-only library, in the vein of https://github.com/r-lyeh/single_file_libs. (See also https://github.com/nothings/stb for a well-known example). These libraries tend to be designed to be simply copied around into the projects that use them. Many, like this one, don’t even bother with assigning version numbers. I’m not a big fan of that style, but it’s an intentional choice. It’s not that CMake integration or pkgconfig files would be wrong or useless here, but I don’t think that adding a build system upstream expressly for the purpose of producing these files (noting that CMake is specifically used only for the tests, not to “build” and install the header!) is something that is likely to be welcomed given the overall minimalist philosophy. My immediate goal in packaging this for Fedora is to allow the submitter of bug 2403985 to run the tests for https://github.com/cutdigital/mcut. That project wants to download the header at build time, # # Download and unpack utest at configure time # FetchContent_Populate( utest GIT_REPOSITORY https://github.com/sheredom/utest.h.git GIT_TAG master GIT_PROGRESS FALSE ) set(utest_include_dir ${utest_SOURCE_DIR}) […] target_include_directories(mcut_tests PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/include ${MCUT_INCLUDE_DIR} ${utest_include_dir} ${mio_include_dir}) but it is always used as #include "utest.h", so a small build-system patch to remove the call to FetchContent_Populate() and the use of utest_include_dir, along with "BuildRequires: utest-static" (due to guidelines on header-only libraries) in the spec file, would be sufficient to get this working. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2412239 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202412239%23c3 -- _______________________________________________ package-review mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
