Re: request review: blogc

[Todd MARTIN <kj4ntv%gmail.com@localhost>]

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’ve 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’ll adjust the language on that for pkgsrc.

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

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

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

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

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 “blog compiler” terminology as that is what upstream uses. I also don’t 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.

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

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.