From: Omar Polo Subject: Re: NEW: www/ssc To: route@dylanharris.org Cc: ports@openbsd.org Date: Fri, 05 Jan 2024 12:05:46 +0100 Hello, On 2024/01/03 17:26:21 +0100, Roger Route wrote: > The command line utility ssc is an opinionated static website nitpicker, > analysing most versions of HTML, XHTML, SVG, & MathML, including > ontologies. It can produce detailed reports, 'repaired' HTML with > resolved server side includes, site statistics, and more. > > > > This is my first submission of a package, anywhere, so please expect > beginner errors. For example, I've not got my head around making man > pages, so the model page, gen.txt, is a text file. It's a solid submission. There are some nitpicks, but overall it's almost perfect :-) > I've built & tested ssc on amd64 & arm64. I can't test other x64 > architectures. It's not written for x32. What do you exactly mean with this? It wasn't tested on 32 bit arches or there is something intrisically that requires a 64 bit arch? Usually we don't limit up front ONLY_FOR_ARCH. (I'd be happy to test on i386, but at the moment boost doesn't seem available in the mirror so i'll wait a new package to pops up before attempting.) > There's a model configuration file for nitpicking the OpenBSD site in > recipe/toast/conf/other. It finds some issues that deserve attention. It seems to mostly complain about the tags that are not closed. While I completely agree, the 'style' used on our site is definitely reliying on the implicit closing rules :/ > I've not sussed how to integrate the github project, > https://github.com/devongarde/ssc. Instead, the package references my > office cat warmer. > > The included test suite is not integrated, it needs tuning for OpenBSD. > Those interested can run it using cmake's ctest in verbose mode. Since it runs, I'd say to remove the NO_TESTS and just let the regress run. The test suite is NOT ran as a part of building the packages during bulks, it's ran "on demand" by developers, so I think it's fine to enable, even if some test are failing. > Finally, I do NOT, in any way at all, claim that ssc produces perfect > results. It is alpha quality, at best. It gets some things vehemently > wrong. Some may disagree with its opinions. I do, however, believe it's > sufficiently useful to mention here. > > Comments most welcome. Here's an an updated tarball adressing a few nitpics :-) - as previously said, I'd remove ONLY_FOR_ARCH. If it really requires a 64 bit arch, I'd set it to ${LP64_ARCHS} - for packages we prefer to dynamically link, to avoid having to 'bump' the REVISION every time a statically linked dependency is updated. In the updated tarball I'm patching CMakeLists.txt to dynamically link to boost, but hunspell is still statically linked and my cmake-fu is not great. - similarly, the patch for CMakeList removes the hardcoded -g and -O flags. We prefer to have optimizations under the control of the ports infrastructure, and similarly for debug info. I think it's fine to keep this patch in the port if upstream you prefer to have -Os by default - curl seems to be disabled in the build, yet it was listed in LIB_DEPENDS - I've re-generated WANTLIB using `make port-lib-depends-check` and copy-pasted its output in the makefile. - For list values (like LIB_DEPENDS) the usual style is to have them sorted and then split one per line. (WANTLIB being a notable exception) - we also use hard tabs in Makefiles instead of spaces for indentation. Then, not really an issue with the port, but just wondering: do you really need to test and adjust the config for every OpenBSD release since 6.8? :-) IMHO, whether to enable curl, hunspell etc. should be tunable via flags (e.g. cmake -DENABLE_FOO=Yes) rather than hardcoded per os (and per os-version!) With hunspell dynamically linked it would be OK op@ to import, thanks!