Re: request review: blogc

Thank you for the feedback.

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

Will keep this in mind. Most of the previous packaging I=E2=80=99ve done =
was on Ravenports a long time ago and there with the other main two =
commiters, in conversations we just always used the term port. But =
I=E2=80=99ll adjust the language on that for pkgsrc.

>=20
> 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".

Added this file in. Was a little confused initially because I don=E2=80=99=
t have really experience working with CVS and using git with pkgsrc-wip, =
but I was able to find example in other packages in pkgsrc-wip to get an =
idea of what I need to do here.

>=20
> Things to fix:
>=20
>  While upstream fails to document prerequisites in README, =
configure.ac
>  looks for a c99 compiler.  Thus add "USE_CC_FEATURES+=3D c99" in a
>  paragraph before GNU_CONFIGURE.  The default USE_LANGUAGES=3Dc does =
not
>  need to be expressed.
>=20
>  Upstream has tests, but TEST_TARGET is not set.  Add
>  "TEST_TARGET=3Dcheck" as a new paragraph after GNU_CONFIGURE.
>=20
>  PLIST has a pkgdir entry for man5, for no apparent reason.

This should be good to go, made changes based on the feedback.

>=20
> Things I suggest improving (that aren't over the line into wrong)
>=20
>  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 :-).

I adjusted the description, hopefully that helps a little more. So give =
some context, blogc is pretty much a static site generator, I used the =
=E2=80=9Cblog compiler=E2=80=9D terminology as that is what upstream =
uses. I also don=E2=80=99t have a problem switching the language to just =
say. A static site generator.

With blogc, you can execute blogc in the terminal giving a template file =
and source file(s) and it will work just fine. An example would be =
something like

blogc -t template.tmpl page_content.txt -o html_page.html

However, an example might be helpful to give what is generally the =
recommended path with blogc.

https://github.com/blogc/blogc-example

The link is to a repo containing a sample repo. So you can have a =
directory structure and then use a build tool like make to do the =
generation.

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

I also made a change to address this also. I agree that it is best not =
to have to repeat the version multiple times.

Thank you once again for reviewing.