allow SESSION_READ_ONLY open a DBI book without write privileges

Geert Janssens geert.gnucash at kobaltwit.be
Wed Jul 15 12:09:31 EDT 2026


I had to go refresh my memory on that one. I didn't bump the doxygen version itself 
really, I merely imported a more recent doxygen.cfg file. That config file happened to 
come from doxygen version 1.9.7. It sets a few new variables, but I think I left all new 
parameters as default.

I believe I had checked repology for the oldest distros we still supported and that lead me 
to doxygen 1.9.7.

I admit I didn't think about what was installed at code to build the nightly doxygen 
documentation.

But honestly, not much has changed as far as I can tell.

I did a test with the current doxygen on my system and added a non-existent variable to 
doxygen.cfg. With that doxygen spits out a warning about an unknown configuration 
parameter but otherwise happily continues to generate the documentation.

So I wonder if the actual issue could be that the two files used by doxygen (doxygen.cfg 
and doxygen_main_page.c) have moved from the docs directory to the top-level directory 
and Derek's build scripts still look for them in the docs directory ?

Geert

Op maandag 13 juli 2026 18:36:50 Midden-Europese zomertijd schreef John Ralls:
> Indeed it is. But IIRC upgrading code is a major undertaking that Derek
> doesn’t have time for.
> 
> Do you remember offhand what feature if any you used in that change that
> prompted raising the Doxygen version?
> 
> Regards,
> John Ralls
> 
> > On Jul 13, 2026, at 07:58, Geert Janssens <geert.gnucash at kobaltwit.be>
> > wrote:
> > 
> > Fedora 29 is quite old by now...
> > 
> > Op maandag 13 juli 2026 02:28:16 Midden-Europese zomertijd schreef Derek Atkins:
> > > Maybe that was the issue.
> > > 
> > > [root at code ~]# rpm -q doxygen
> > > doxygen-1.8.14-7.fc29.x86_64
> > > 
> > > -derek
> > > 
> > > On Sun, July 12, 2026 2:10 pm, John Ralls wrote:
> > > > Derek,
> > > > 
> > > > That doesn’t square with the last build being two years ago, we
> > > > removed
> > > > auto tools in 2017. https://github.com/Gnucash/gnucash/pull/1943,
> > > > which
> > > > was merged immediately after the last successful docs build is the
> > > > culprit. What version of Doxygen are you running?
> > > > https://github.com/Gnucash/gnucash/pull/1943/changes/891b921c811f32e21
> > > > 4fe9
> > > > fc1a87e392b58ed7757 bumped the Doxyfile version from 1.8.3 to 1.9.7.
> > > > 
> > > > Regards,
> > > > John Ralls
> > > > 
> > > >> On Jul 11, 2026, at 18:08, Derek Atkins <derek at ihtfp.com> wrote:
> > > >> 
> > > >> Yes, doxygen not building is a known issue.  The build requirements
> > > >> changed and I've never spent the time to figure out how to update the
> > > >> script to meet the new requirements.  Specifically I used to be able
> > > >> to
> > > >> build the doxygen.cfg manually by calling the Makefile.am with the
> > > >> right
> > > >> rule.  But that was removed for CMake, and I think to get that to
> > > >> work I
> > > >> might need to install a complete build system, which I kinda don't
> > > >> want
> > > >> to do.  Worst case I'll have to make VM just for that..  But it just
> > > >> hasn't been high on my priority list.
> > > >> -derek
> > > >> Sent using my mobile device. Please excuse any typos.
> > > >> 
> > > >> On July 11, 2026 16:18:15 John Ralls <jralls at ceridwen.us> wrote:
> > > >>> Noah,
> > > >>> 
> > > >>> Please always copy one of the mailing lists when you email one of
> > > >>> the
> > > >>> GnuCash developers unless it’s to send something like a GnuCash
> > > >>> book;
> > > >>> in that case the email should just have the file, all of the
> > > >>> discussion
> > > >>> around it should be copied to the list.
> > > >>> 
> > > >>> I’ve passed on to Derek via IRC the Doxygen-docs problem just in
> > > >>> case
> > > >>> he misses it here.
> > > >>> 
> > > >>> Yup, readonly-mode is largely cosmetic and applied only to the GUI.
> > > >>> GnuCash is not designed for use by more than one user at a time and
> > > >>> read-only mode is very simplistic.
> > > >>> 
> > > >>> I don’t think it would be too hard to extend its force to the
> > > >>> backend
> > > >>> so that a read-only session is blocked from writing. But if you want
> > > >>> a
> > > >>> read-only session to lock the database then it’s not really
> > > >>> read-only
> > > >>> anymore.
> > > >>> 
> > > >>> How about leveraging the database’s locking? Wrap all of the queries
> > > >>> with dbi_conn_transaction_begin and dbi_conn_transaction_commit.
> > > >>> That
> > > >>> will make multi-table writes atomic with an exclusive lock, blocking
> > > >>> a
> > > >>> reader from reading them until the whole write is complete, while a
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20260715/7c03e789/attachment-0001.htm>


More information about the gnucash-devel mailing list