Hi, guys,

Apologies, I forgot the cc. :-(

I'm most happy with Omar's proposed tarball.

:-)


-------- Forwarded Message --------
Subject: Re: NEW: www/ssc
Date: Thu, 11 Jan 2024 07:04:16 +0100
From: Roger Route <route@dylanharris.org>
Reply-To: route@dylanharris.org
Organisation: Harris
To: Omar Polo <op@omarpolo.com>



On 05/01/2024 12:05, Omar Polo wrote:
> Hello,

Hi! Sorry about my tardy response to your kind reply, I was away.

> 
> 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 :-)

Thank you!

> 
>> 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.)

The x32 build broke a while ago and I never got around to fixing it. I 
could certainly look at it again, but that will take a little time.

I could only test on those two x64 architectures, and don't feel that I, 
personally, am in a position to make any implicit promises that ssc 
would build and work correctly on the others: I lack experience of them, 
and I lack test kit. Obviously, you have significantly more experience 
of porting to them, so if you say it'll be ok, I'll follow your suggestion.

> 
>> 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 :/

The WhatWG HTML5 Living Standard says unclosed tags cause browser 
inefficiency, and I'm not arguing with those guys given they're the ones 
who write the browsers. ssc can be seen as an HTML linter, except that 
it can be obnoxiously opinionated, and a linter really should point out 
things like that. Anyway, such warnings can be configured away.

> 
>> 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.

Ok

> 
>> 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 :-)

I'm certainly happy to conform to standard practice here. All your 
nitpicks(!) make sense to me.

> 
>   - 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 been having a bit of an argument with curl in recent versions of 
OpenBSD, but, it appears, failed to keep the CMake file in step.

> 
>   - 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!)

My CMake-fu is poo too. I can't really defend my approach, it just 
evolved that way. I'm absolutely sure I could improve this, and I'll 
look at your suggestion. Generally, I disabled certain options in 
certain builds because I couldn't persuade them to behave, although 
admittedly I didn't try so hard.

> 
> With hunspell dynamically linked it would be OK op@ to import, thanks!
> 

I'll respond soon (I hope) with an update that conforms to the standards 
here, along with your suggestions.

Thank you for taking the time to look and respond to my proposed port.

:-)

Dylan Harris