Source directory restructuring
bhardwajs at gmail.com
Tue Aug 8 10:50:17 EDT 2017
If the plan is to dump autotools, should we ask also devs to make sure that
they can build using cmake? I have had problems in the past and therefore,
I have stuck with autotools so far.
What are the things we want to confirm in the cmake toolchain?
On Tue, Aug 8, 2017 at 7:36 AM, John Ralls <jralls at ceridwen.fremont.ca.us>
> > On Aug 8, 2017, at 10:29 AM, Geert Janssens <geert.gnucash at kobaltwit.be>
> > On maandag 7 augustus 2017 21:27:18 CEST John Ralls wrote:
> >> These are to be top-level directories, so the current src goes away,
> >> The rest assumes that to be the case.
> > Yes, I would drop src.
> >> Let's call the libgnucash directory libgnucash instead of just lib and
> >> lib as the place put code pinched from elsewhere like the bits of
> >> libgoffice.
> > That's reasonable.
> >> I want to get rid of gnc-module too, but it's not easy.
> > Indeed. I didn't plan this in the first phase. Except perhaps for some
> > hanging fruit (like what I did with a couple of reports subdirectories) I
> > don't think this is something to target for 2.8.
> >> App-utils has stuff that belongs in libgnucash and other stuff (e.g.
> >> options) that belongs in the application directory (which I propose
> >> "gnucash" below). There's also code splattered all over everywhere else
> >> that belongs in libgnucash. How much of a prerequisite to rearrangement
> >> getting the code in the right place?
> > There's a gui and non-gui aspect to the options. The gui aspect clearly
> > go to the "gnucash" part. The non-gui aspect probably not. In my long
> > idea libgnucash should be able to generate reports (but not display
> them) to
> > allow the bindings (and eventual smartphone apps) access to this
> feature. As
> > things stand now, the report system requires the options. We all agree of
> > course the options are currently a complicated mixture of C and guile
> > which needs serious modernization. That will not be for 2.8.
> > But your general message stands. Lots of code is in the wrong functional
> > source group. And there definitely won't be time to reorganize all of
> >> I think that having separate documentation directories (there are two,
> >> and src/doc) is an abject failure from a maintenance standpoint. A lot
> >> stuff was written 15-20 years ago and was marked obsolete 10 years ago
> >> because it's been left to rot. All documentation needs to be in the
> >> files as Doxygen comments. We should look through the docs and src/docs
> >> stuff and copy anything that's still relevant into comments in the
> >> appropriate source files and delete the docs directories.
> > Good idea.
> >> I'd prefer that the application code go into a directory named gnucash
> >> rather than "ui". I'm inclined toward removing cutecash entirely. It
> >> sense for Christian to keep it in the Gnucash repository when we were
> >> SVN, but now he should just publish it in his own Github repo.
> > I realize I'm somewhat hesitant to drop cutecash from the repo. It looks
> I'm a
> > bit emotionally attached to it (although I never used it and only built
> > once to test). That's probably because it's a decent first attempt to
> use qt
> > instead of gtk. And qt for me is one of the few options that can bring
> us one
> > code base for all form factors. (Drifting off into dreaming about
> > Anyway sticking with the current situation I believe you are right to
> > removing it. It's not maintained, and based on the soon to be obsolete
> Qt4 and
> > most importantly it can be recovered should we ever want to do so or are
> > to go the Qt way and need a base to start from.
> >> The bindings are mostly (and should probably be entirely) libgnucash
> >> bindings. They really belong in libgnucash or failing that in their own
> >> TLD, not part of the application.
> > TLD then.
> >> Reports might stand on their own as a separate dependency of gnucash or
> >> could be a subdirectory of gnucash. The same is true of import-export.
> >> one approach the GUI parts of each would be part of the application
> >> the functional bits would be part of libgnucash. Are the matchers
> >> libgnucash or gnucash?
> > Long term I would like to see the functional part of both reports and
> > export be part of libgnucash and the gui's go into gnucash. I think
> there are
> > use cases where smartphone apps and the bindings would benefit from this.
> > For 2.8 that would again be too much work. For this initial step I'd
> > the plugins directory to be the location to store self-contained,
> > modules. There are already a few smaller ones in there. I'd add the
> report and
> > import/export directories in there as well until we're ready to split
> them up.
> > My work on the csv importer is an important step in the right direction.
> > the next major cycle I hope to continue this for the other importers and
> > exporters as well.
> >> Gtk+ is very much Gnome and depends on other pieces of the Gnome
> >> The actual name of the directory isn't really important so we can call
> >> gtk if you'd rather, but there are lots of other Gnome project
> >> that aren't going away as long as we're using Gtk+. Remember that in
> >> addition to gnome, gnome-util, and gnome-query there's also
> >> report-gnome, and (until your latest changes) business-gnome. There's
> >> Gtk+ code in import-export, html, and probably a few other places that
> >> don't immediately come to mind. Setting that aside we still have all of
> >> that GValue and g_object_set/get code that we use for communicating
> >> the engine, the backends, and the importers.
> >> I'll point out once again that there's an immense amount of untangling
> >> separate the actual UI code from glue and actual bits of libgnucash that
> >> are all mangled together in the various gnome directories.
> > All true. I preferred gtk as that's the name of the toolkit the code is
> > on, whereas gnome these days refers more to a user community and a
> > environment.
> >> Does it really make sense to push much further with this for 2.8? I'd
> >> to move towards releasing that as quickly as we can, then we can move
> on to
> >> extraction and rearrangement.
> > I share your concern about getting 2.8 out as soon as possible. I'm
> trying to
> > balance this concern with a potential maintenance burden in the next
> > cycle. If we do the directory shuffling early in the next major cycle
> the 2.8
> > (then to be maint branch) and the new master branch will have a rather
> > diverging source directory structure which means developers have to keep
> > structures in their head for one major cycle.
> > I understand it's impossible to clean it all up in the few weeks we have
> > before we start the 2.8 end game. So I don't expect to be able to do
> more than
> > some very basic top-level restructuring. My hope is this will more
> clearly set
> > the intention for each source directory and may help in deciding which
> > should go where. And 2.8 maintenance and new master will have the same
> > source structure reducing some of the confusion.
> > The real uncluttering will be for the next major cycle.
> OK, I think we're in complete agreement. Let's go ahead and move current
> directories into gnucash and libgnucash, recognizing that a) there's plenty
> of code that's going to get moved after we branch 2.8 and b) that the two
> will be interdependent--meaning that the build system may have to bounce
> back-and-forth building modules in one and then the other until we get it
> CMake will do better at optimizing the dependencies once it's informed of
> them all so we should probably dump autotools as part of this rearrangement.
> John Ralls
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel