An update to Davenport
I’m trying to spin-up a new instance of socelect.org and need to compile the Davenport library for it.
This was a bit of an eye opener. I myself wasn’t able to do it. How do I expect anyone else to? The install simply wouldn’t work.
The reason for this is that I had not tested the install “from scratch” since
writing the command line program for trying-out the library. When installing
from nothing, from a git clone
of the source, there’s a Catch 22.
The command line program won’t compile without the library. The library
won’t compile because the command line program won’t compile.
Well now, this is embarrassing.
To fix it meant some fiddling with GNU Autoconf and some directory reorganizing. More than a little fiddling, actually. About a day’s worth.
It isn’t perfect, what I came up with. Now the need for the Cutter testing library is confined to compiling the tests. The command line executable will not compile without first compiling and installing the davenport library. However, that is now possible, more straightforward.
Aside, CMake
As an aside, while web searching an error message I found an answer on askUbuntu in which a user with name, “Qix” begs people not to use the GNU Autoconf tool chain. They want people to use CMake instead. Looking at that, wow. It’s a whole new beginning.
CMake is one of those open source, “free” software efforts that supports itself with training. This always signifies to me that it isn’t free, that the documentation you need to truly get up to speed with it is in courseware or courses that you have to pay for. A quick look gave me some validation of that suspicion. I didn’t find a “Getting started” document, for example, nor any kind of overview. The docs were reference materials that went straight down into the weeds.
This isn’t entirely a fair assessment. There’s a book available online via the menu, Mastering CMake. There’s nothing wrong with making money by producing a good product and offering consulting for it.