The "version number" is a SHA3-256 hash that identifies a particular check-in. The latest "version" as I write this is:

• ae3317b0ec2e635cb14ff65ff4225a5647533d48d5dcc9831fd0268792a2b09d

I suppose Homebrew wants to see a traditional X.Y.Z version number in addition to this?

I can tag the latest check-in as "version-1.0.0" if that helps. But the text "1.0.0" does not appear anywhere in the source tree. Does there also need to be a VERSION file that contains the version number or something? Does the version number need to be embedded in the compiled code someplace? How do people access the version number? What are Homebrew's requirements?

A particular version of the code can also be identified by the ISO 8601 timestamp of the check-in. Would this work any better for Homebrew? The latest check-in is at 2024-02-12T20:10:10 and can be accessed as:

• https://pikchr.org/home/info/2024-02-12T20:10:10

The date can also be expressed as a pure number, omitting the punctuation:

• https://pikchr.org/home/info/20240212201010

Would 20240212201010 be an acceptable version number for homebrew?

Tagging the latest checking as "v1.0.0" would be fine -- it would enable homebrew to download a zip of the sources at that tag from github, and it's a version number in a format that users expect.

The problem with using the sha number as a version is that it's not sequential -- I cannot tell if version 1234abcd is earlier or later than another.

Using the timestamp is quite unusual -- it's harder to read, and it does not enable you to express the nuances of minor change versus major change

Who among the readers of this forum would object to me creating an empty check-in off of the tip of trunk and calling it "version-1.0.0"? I'll do so in about 24 hours if there are no "Nays".

it would enable homebrew to download a zip of the sources at that tag from github

Do they insist on using GitHub? If not, then the ZIP archive can be obtained from the canonical repository using URLs like this:

• https://pikchr.org/home/zip/ae3317b0ec2e63/pikchr-ae3317b0ec2e63.zip
• https://pikchr.org/home/zip/20240212201010/pikchr-20240212201010.zip

Aside: I deliberately did not make those examples hyperlinks, because I don't want spiders downloading millions of copies.

The url is indifferent, I think, but are you sure you prefer homebrew users to download from your url? I will use whichever you prefer

A fair point. I'll plan on tagging version-1.0.0 then.

Hi, any updates on this?

The latest trunk check-in has now been tagged as "version-1.0.0".

An update on this. My pull request is blocked because the maintainers are requesting that I request the Pikchr developers to add a ./configure step to the build.

I told them that I don't think this makes sense in the context of this program, and that things like the compiler to use are configurable already on the command line by overriding the CC make variable, but it seems they are not satisfied with this.

In case you want to see the conversation, it's here: https://github.com/Homebrew/homebrew-core/pull/166871

I looked at adding a configure script. It doesn't seem like it would be hard - for somebody who knows autoconf. I've done a few ./configure files in the past but that was long, long ago, and my ./configure skills are not up-to-date. Anything I come up with is likely to violate some unwritten "best practice".

I'm guessing that somebody who is reading this can throw together a suitable configure script for pikchr in about 5 minutes. If so, please do so and email me (drh at sqlite dot org).

Autosetup should be close enough to satisfy this requirement.

If you can wait a week or so, I might be able to get to it myself. (This week is a mess for me.)

Just touching base, has this made the top of some priority queue yet? I'm not a Mac user, but this would be a nice little package to add, and I didn't see it when I landed here.

[C]{1}[h]{1}[e]{2}[r]{1}[s]{1} brickviking
(Post 4)