Register2

[Robert Fewell]

Another thing I did not know about. I have added bug 710830 which adds a
configure option --enable-register2 and with this set will compile Gnucash
as is. If not enabled, default, Gnucash will look like before and operate
the same way. There is also an option to use Gnucash with the --extra
switch which adds some basic options to the Extensions menu, Open Account,
Open Sub Account and GL for testing.

I think I have correctly added the configure option but this may need
changing. Was unsure about the number of #ifdef's but I think they are
correct to achieve what is required.

Regards.

    Robert


On 24 October 2013 08:32, Geert Janssens <janssens-geert at telenet.be> wrote:

> **
>
> Robert,
>
>
>
> Yet another option is to use gnucash' --extra switch. This is a runtime
> command line switch that is used to show some additional menu items in a
> menu called "Extra".
>
>
>
> While developing you could move the actions related to Register2 to this
> menu and every user can test them simply by adding --extra to the gnucash
> command line.
>
>
>
> The added advantage is that your code will get compiled each time. This
> helps prevent bitrot. With a configure option your code will only get
> compiled if a developer explicitly enables the option.
>
>
>
> Geert
>
>
>
> On Wednesday 23 October 2013 14:12:36 Robert Fewell wrote:
>
> > OK, I have worked out how to add a configure option to disable the
>
> > register2 parts, will raise bug with patch later.
>
> >
>
> > Robert
>
> >
>
> > On 23 October 2013 11:41, Geert Janssens <janssens-geert at telenet.be>
> wrote:
>
> > > **
>
> > >
>
> > > On Tuesday 22 October 2013 12:49:57 John Ralls wrote:
>
> > > > On Oct 22, 2013, at 11:34 AM, Geert Janssens
>
> > > > <janssens-geert at telenet.be>>
>
> > > wrote:
>
> > > > > I do encourage you to get used to svn/git, and as John proposes,
>
> > > > >
>
> > > > > clone the gnucash repository on github. I'm not sure what would
>
> > > > > be
>
> > > > >
>
> > > > > the best starting point for a branch, r23314 (which you would
>
> > > > >
>
> > > > > revert immediately in your next commit), or r23313, which
>
> > > > > doesn't
>
> > > > >
>
> > > > > need any reverting. Both will cause some rebasing/merging issues
>
> > > > >
>
> > > > > eventually. Perhaps John has a better idea.
>
> > > > >
>
> > > > >
>
> > > > >
>
> > > > > In any case, it would be good if you regularly push your
>
> > > > > development
>
> > > > >
>
> > > > > branch in your github clone so other developers can follow your
>
> > > > >
>
> > > > > progress.
>
> > > >
>
> > > > On Oct 22, 2013, at 12:09 PM, Christian Stimming
>
> > > > <christian at cstimming.de>>
>
> > > wrote:
>
> > > > > Just removing the code will almost surely introduce plenty of
>
> > > > >
>
> > > > > merging errors the next time any of us or you try to merge
>
> > > > >
>
> > > > > non-trivial changes from gnucash SVN. Basically, if you remove
>
> > > > > the
>
> > > > >
>
> > > > > code, it means you are going to maintain a private branch of
>
> > > > >
>
> > > > > gnucash SVN, not in any git or svn management, but just by
>
> > > > > keeping
>
> > > > >
>
> > > > > the changed files on your local harddisk. Out of the many
>
> > > > > available
>
> > > > >
>
> > > > > options of maintaining a separate branch (be it git somewhere or
>
> > > > >
>
> > > > > svn somewhere or whatever), this one is definitely the worst
>
> > > > >
>
> > > > > choice. I'd strongly suggest to create a configure switch
>
> > > > > instead,
>
> > > > >
>
> > > > > and keeping almost all code in SVN as well.
>
> > > >
>
> > > > Looks like Geert reverted the reversion patch.
>
> > > >
>
> > > >
>
> > > >
>
> > > > I was going to suggest that Robert branch after the reversion
>
> > > > patch
>
> > > >
>
> > > > and immediately revert it in his branch:
>
> > > >
>
> > > > git revert 22eff28
>
> > > >
>
> > > > Then he can rebase from trunk periodically
>
> > > >
>
> > > > git rebase trunk reg-2-branch
>
> > > >
>
> > > > to prevent bit-rot on his branch. I do this on my private feature
>
> > > >
>
> > > > branches, it works quite well.
>
> > >
>
> > > That approach is fine with me as well, but wouldn't that result in
>
> > > more merge conflicts as time goes by ?
>
> > >
>
> > >
>
> > >
>
> > > Hmm, I'll just stop reverting reversals and let Robert choose what
>
> > > he
>
> > > prefers.
>
> > >
>
> > >
>
> > >
>
> > > Geert
>
>
>