Good afternoon, On Mon, Nov 2, 2020 at 11:56 AM John Ralls <jra...@ceridwen.us> wrote: > > > > > On Nov 2, 2020, at 9:22 AM, Glenn Serre <gase...@spiresoftware.com> wrote: > > > > Good morning, > > > > My name is Glenn Serre, and I have recently retired from paid software > > development work, which I had been doing since near the end of the > > last millennium. > > > > I have been using gnucash on Linux for many years and would like to > > contribute. I intend to start by doing some conversion to C++ as that > > will help me learn the system, fits well with my experience, and will > > incent me to update my C++ skills (yet again). I have read the C++ > > wiki page and intend to start with the xml backend. > > > > Initial questions: > > Is there a better place to start than the xml backend? > > Are we still limiting things to what is supported in C++ 11 and Boost? > > Any gotchas, etc. that are not documented in the wiki? > > > Welcome! > > I think you'll learn the Gnucash innards more quickly by taking on some > engine bugs and rewriting some engine code to C++; that's where the business > logic lives and it's the key to understanding the spaghetti pot; > understanding the engine is a necessary prerequisite for understanding the > backends. I personally find writing tests to be an excellent way of > understanding how code works and there's plenty of code that isn't well > tested. > > Regarding the XML backend, the medium-term plan is to convert the XML backend > from creating engine objects directly to creating an in-memory SQLite3 > database so that we can replace QOFQuery with SQL queries and towards loading > engine objects as needed instead of all of them at startup. That plan argues > against putting much effort into a straight functional rewrite. >
OK. I will look at libgnucash/engine C files and engine bugs. > As for C++, we're up to C++17 now for new work. We do still want to limit > external dependencies to Boost (although we've decided on Googletest instead > of Boost::testing for the unit test framework). That doesn't mean that > something else is off limits if there's a really compelling case for it, but > you would need to make that case. > OK. I would not expect to be arguing for additional dependencies (fewer is better) and certainly not in the near term. > Undocumented gotchas? You bet, including plenty of what Rumsfield famously > named "unknown unknowns". Gnucash spaghetti has been cooking for 23 years > now, it's thoroughly tangled! > > BTW, consider connecting on the IRC channel as a more conversational and > (depending on your timezone) immediate channel for discussing code. > https://wiki.gnucash.org/wiki/IRC Done, but I expect to be just lurking for a while. Thanks! -- Glenn S. > > Regards, > John Ralls > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
