Source directory restructuring

[Sumit Bhardwaj]

John,

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?
cmake
cmake install
cmake check

Anything else?

Thanks,
Sumit

On Tue, Aug 8, 2017 at 7:36 AM, John Ralls <jralls at ceridwen.fremont.ca.us>
wrote:

>
> > 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
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>