Hello,

On 2024/01/03 17:26:21 +0100, Roger Route <route@dylanharris.org> 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!

• ssc.tar.gz (2K)