Source directory restructuring

[John Ralls]

> On Aug 8, 2017, at 10:29 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> 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, right?
>> 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 keep
>> 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 low 
> 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 calling
>> "gnucash" below). There's also code splattered all over everywhere else
>> that belongs in libgnucash. How much of a prerequisite to rearrangement is
>> getting the code in the right place?
>> 
> There's a gui and non-gui aspect to the options. The gui aspect clearly should 
> go to the "gnucash" part. The non-gui aspect probably not. In my long term 
> 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 code 
> 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 that.
> 
>> I think that having separate documentation directories (there are two, doc
>> and src/doc) is an abject failure from a maintenance standpoint. A lot of
>> 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 source
>> 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 made
>> sense for Christian to keep it in the Gnucash repository when we were using
>> 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 it 
> 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 Utopia...)
> 
> Anyway sticking with the current situation I believe you are right to consider 
> 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 ready 
> 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 they
>> could be a subdirectory of gnucash. The same is true of import-export. In
>> one approach  the GUI parts of each would be part of the application while
>> 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 import/
> 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 consider 
> the plugins directory to be the location to store self-contained, loadable 
> 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. For 
> 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 project.
>> The actual name of the directory isn't really important so we can call it
>> gtk if you'd rather, but there are lots of other Gnome project dependencies
>> 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 register-gnome,
>> report-gnome, and (until your latest changes) business-gnome. There's also
>> 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 between
>> the engine, the backends, and the importers.
>> 
>> I'll point out once again that there's an immense amount of untangling to
>> 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 based 
> on, whereas gnome these days refers more to a user community and a desktop 
> environment.
> 
>> Does it really make sense to push much further with this for 2.8? I'd like
>> 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 major 
> 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 two 
> structures in their head for one major cycle.
> 
> I understand it's impossible to clean it all up in the few weeks we have left 
> 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 code 
> should go where. And 2.8 maintenance and new master will have the same basic 
> source structure reducing some of the confusion.
> 
> The real uncluttering will be for the next major cycle.

Geert,

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 untangled.

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.

Regards,
John Ralls