You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The master branch does build on e.g. Fedora 37, if ignoring warnings about deprecated stuff. (Several "warning: 'GTimeVal' is deprecated: Use 'GDateTime'".) autogen (autoupdate) does also give some warnings and suggestions for modernizing.
For reaching the goal of being able to distribute binary GnoTime distribution packages, those would need to include libqof binary. Or we would need to resurrect/adopt earlier libqof binary packages and get them back so we can depend on them.
Although, for binary distribution, I would be interested in primarily targetting Flatpack, and the idea would be it would include the libqof binary.
With the codehelp/qof seeing very little activity for many years and no binary packages available in dists, it of course also raises the question of if there is a risk that this source code suddenly disappears. To mitigate that, we could fork the qof repo into the GnoTime github organisation. That would probably be simpler compared to embedding the source code into the GnoTime repo, although that is another option. A separate repo (with light modifications) could have benefits in terms of incorporating changes from upstream, in case there is some activity again. And for sending any changes we make to upstream.
A completely different approach would be to get rid of libqof entirely. Maybe load up the data in a temporary sqlite if we want to use SQL. I have not investigated this.
The text was updated successfully, but these errors were encountered:
This issue is meant to track and discuss what to do about QOF.
Source code: https://github.com/codehelp/qof
The master branch does build on e.g. Fedora 37, if ignoring warnings about deprecated stuff. (Several "warning: 'GTimeVal' is deprecated: Use 'GDateTime'".) autogen (autoupdate) does also give some warnings and suggestions for modernizing.
For reaching the goal of being able to distribute binary GnoTime distribution packages, those would need to include libqof binary. Or we would need to resurrect/adopt earlier libqof binary packages and get them back so we can depend on them.
Although, for binary distribution, I would be interested in primarily targetting Flatpack, and the idea would be it would include the libqof binary.
With the codehelp/qof seeing very little activity for many years and no binary packages available in dists, it of course also raises the question of if there is a risk that this source code suddenly disappears. To mitigate that, we could fork the qof repo into the GnoTime github organisation. That would probably be simpler compared to embedding the source code into the GnoTime repo, although that is another option. A separate repo (with light modifications) could have benefits in terms of incorporating changes from upstream, in case there is some activity again. And for sending any changes we make to upstream.
A completely different approach would be to get rid of libqof entirely. Maybe load up the data in a temporary sqlite if we want to use SQL. I have not investigated this.
The text was updated successfully, but these errors were encountered: