Re: request review: blogc

Todd MARTIN <[email protected]> writes:

> I have a new port I want to introduce called blogc that I have
> available in pkgsrc-wip. I was hoping someone could review it and
> provide some feedback for me.

(We have "packages"; in NetBSD "port" refers to a machine hardware type,
e.g. vax or amd64.)

It looks very good; pkglint shows only one issue, the lack of COMMIT_MSG
(that could be used to add it to pkgsrc with "cvs commit -F COMMIT_MSG".

Things to fix:

  While upstream fails to document prerequisites in README, configure.ac
  looks for a c99 compiler.  Thus add "USE_CC_FEATURES+= c99" in a
  paragraph before GNU_CONFIGURE.  The default USE_LANGUAGES=c does not
  need to be expressed.

  Upstream has tests, but TEST_TARGET is not set.  Add
  "TEST_TARGET=check" as a new paragraph after GNU_CONFIGURE.

  PLIST has a pkgdir entry for man5, for no apparent reason.

Things I suggest improving (that aren't over the line into wrong)

  COMMENT/DESCR says blog compiler, and a reasonable person would expect
  a static site generator for a blog site, similar to hugo (and many
  others, which are different but serve the same purpose).  I think this
  package is different but it would take me most of an hour to really
  figure that out.  Crisply *decribe what the program does* so that
  people that do understand hugo etc. and have that expectation, and
  people that do not understand hugo, all end up with the correct
  impression.  The key question: Suppose I write 9 blog entries in
  files.  Can I then run the programs in this package to get a complete
  set of html (and maybe css) that I can just stick in my webroot?  If
  yes, and I have to construct scripts to do this, then maybe call it
  "static blog site generator toolkit".  If I can store blog entries and
  config in a dir and just "blogc --build-site .", it's a static blog
  site generator.  If I need to do a bunch of other things, then it's
  something else.  (If there isn't adequate text to steal from upstream,
  an upstream bug report is likely in order :-).

  Perhaps controversial, but I see having the version number twice in
  the Makefile as a bug.   I tend to VERSION= as the first line of
  first stanza, and then ${VERSION} in later variables, when it is
  needed more than once.