2019-10-01 GnuCash IRC logs
00:05:09 *** ArtGravity has quit IRC
00:59:00 *** Mechtilde has joined #gnucash
01:02:45 *** Agfarmer18 has quit IRC
01:08:18 *** Mechtilde has quit IRC
01:08:54 *** Mechtilde has joined #gnucash
01:34:55 *** fell_laptop has joined #gnucash
01:34:55 *** ChanServ sets mode: +o fell_laptop
01:36:38 *** fell has quit IRC
01:42:46 *** pohly1 has joined #gnucash
02:03:26 *** sbluhm has joined #gnucash
02:03:26 *** ChanServ sets mode: +v sbluhm
02:08:42 *** Mechtilde has quit IRC
02:25:36 *** sbluhm has quit IRC
02:29:11 *** fabior has joined #gnucash
02:30:36 *** sbluhm has joined #gnucash
02:30:36 *** ChanServ sets mode: +v sbluhm
02:59:57 *** fell_laptop has quit IRC
03:00:17 *** fell_laptop has joined #gnucash
03:00:17 *** ChanServ sets mode: +o fell_laptop
03:04:09 *** fell_laptop is now known as fell
03:24:01 *** bertbob has quit IRC
03:26:59 *** bertbob has joined #gnucash
03:26:59 *** ChanServ sets mode: +v bertbob
03:35:30 *** Mechtilde has joined #gnucash
03:36:24 *** Mechtilde has joined #gnucash
03:45:44 *** fell has quit IRC
03:45:48 *** fell_laptop has joined #gnucash
03:45:48 *** ChanServ sets mode: +o fell_laptop
03:55:52 *** bertbob has quit IRC
04:13:01 *** bertbob has joined #gnucash
04:13:01 *** ChanServ sets mode: +v bertbob
04:24:17 *** gjanssens has joined #gnucash
04:24:17 *** ChanServ sets mode: +o gjanssens
05:04:47 *** chris has joined #gnucash
05:04:47 *** ChanServ sets mode: +v chris
05:12:59 <chris> gjanssens thanks for fixing master... I'd have sworn I checked and it didn't fail.
05:13:06 <chris> not sure why travis didn't flag it
05:13:51 <gjanssens> chris: you're welcome
05:15:52 *** phoenix has joined #gnucash
05:23:26 *** phoenix has quit IRC
05:41:25 *** phoenix has joined #gnucash
05:50:18 *** fell_laptop has quit IRC
05:50:27 *** fell_laptop has joined #gnucash
05:50:27 *** ChanServ sets mode: +o fell_laptop
05:55:38 *** Aussie_matt has quit IRC
05:56:52 *** fabior has quit IRC
06:00:00 *** phoenix has quit IRC
06:12:24 <chris> do we want <!DOCTYPE html> in reports? it's one step towards satisfying the validator...
06:13:05 *** Aussie_matt has joined #gnucash
06:25:33 <gjanssens> chris: isn't that in the reports currently ?
06:28:36 *** fell_laptop has quit IRC
06:29:59 *** fell has joined #gnucash
06:29:59 *** ChanServ sets mode: +o fell
06:30:13 *** fell_laptop has joined #gnucash
06:30:13 *** ChanServ sets mode: +o fell_laptop
06:30:13 *** fell_laptop has quit IRC
06:30:13 <chris> nopes!
06:30:36 <chris> <html dir='auto'> is the first line nowadays
06:31:44 *** oozer has joined #gnucash
06:38:33 *** fell has quit IRC
06:38:42 *** fell has joined #gnucash
06:38:42 *** ChanServ sets mode: +o fell
06:41:47 *** Jimraehl1 has joined #gnucash
06:43:32 *** Jimraehl1 has quit IRC
06:48:02 <gjanssens> chris: hmm I only checkedo one report which happened to be an e-guile based one and that one still has the DOCTYPE line
06:48:25 <gjanssens> I'm in favor of adding such a line for all reports, but do check our source history
06:49:10 <gjanssens> There have been layout issues related to the report header files in the past and ISTR we adjusted it several times to fix those
06:49:41 <gjanssens> Browsers are picky...
06:56:05 <chris> gjanssens: I think the most picky will be multicolumn and it tolerates DOCTYPE well. my changes will only add it once when <html> also rendered.
06:57:24 <chris> the only issue is... if multicolumn includes eguile report it'll include eguile's full header...
06:57:42 <chris> still, layout is fine
06:57:50 <chris> anyway just an idea, let's scrap
06:58:25 *** fell_laptop has joined #gnucash
06:58:25 *** ChanServ sets mode: +o fell_laptop
06:58:42 *** fell has quit IRC
06:58:57 *** fell_laptop has quit IRC
07:02:31 *** fell has joined #gnucash
07:02:32 *** ChanServ sets mode: +o fell
07:14:55 *** CDB-Man_ has joined #gnucash
07:14:55 *** ChanServ sets mode: +v CDB-Man_
07:17:21 *** CDB-Man has quit IRC
07:41:25 <gjanssens> chris: you can look at the commit messages of older commits in this area to find out what issues we had exactly
07:41:37 <gjanssens> It's possible it happened only on specific platforms.
07:41:45 <gjanssens> It's too long ago to remember clearly
07:47:18 *** fell_laptop has joined #gnucash
07:47:18 *** ChanServ sets mode: +o fell_laptop
07:47:18 *** fell has quit IRC
07:51:19 *** jervin has joined #gnucash
08:01:25 <gjanssens> jralls: I'm revisiting the CMakeLists.txt files in libgnucash (experimenting to move the guile bindings outside of it)
08:03:34 *** omnireq_ has joined #gnucash
08:03:40 *** omnireq has quit IRC
08:12:46 <gjanssens> I notice in core-utils we add ${GTK_MAC_CFLAGS_OTHER}
08:13:29 <gjanssens> For starters, I assume this is MacOS only, so it could potentially be included only conditionally
08:13:52 <gjanssens> However, what I'm more interested in is why do we include this in the first place ?
08:14:31 <gjanssens> core-utils doesn't have any GTK dependency. Is this just an oversight or is it required for reasons I'm not aware of ?
08:23:51 *** Aussie_matt has quit IRC
09:02:00 *** fabior has joined #gnucash
09:50:29 *** chris has quit IRC
09:52:22 *** chris has joined #gnucash
09:52:22 *** ChanServ sets mode: +v chris
10:05:41 *** mohave has joined #gnucash
10:19:21 *** jervin has quit IRC
10:23:52 *** omnireq_ has quit IRC
10:30:14 <warlord> Hmm.. Has anyone looked at Homebank?
10:33:35 <warlord> Looks like it's not full double-entry.
10:33:49 <warlord> But it looks like it might have some interesting reports.
10:34:05 <warlord> It's GTK based, so might be interesting to look at what it's using.
10:36:16 *** Mechtilde has quit IRC
10:37:14 *** fell_laptop has quit IRC
10:43:46 *** pohly1 has quit IRC
10:46:55 *** pohly1 has joined #gnucash
10:58:23 *** omnireq has joined #gnucash
10:58:23 *** ChanServ sets mode: +v omnireq
11:05:49 <gjanssens> jralls: https://github.com/Gnucash/gnucash/blob/maint/libgnucash/core-utils/CMakeLists.txt#L154 - where does this "CORELE" come from ?
11:06:40 <gjanssens> You added it in https://github.com/Gnucash/gnucash/commit/4ecd9c2dd41ae75ec4e82a662a241543fc075c01 but I have no clue why
11:12:10 <chris> warlord: patches... ;)
11:15:19 <warlord> chris, what about patches?
11:15:34 <chris> ... welcome
11:15:44 <warlord> People have talked about ripping out scheme, so looking at what system others use for reports would be a first step.
11:16:03 <warlord> chris, I'm not asking for anything.
11:16:14 <warlord> Just suggesting another package to look at for ideas.
11:22:09 * chris would be grateful for guidance about 4.x branches in due course
11:29:05 *** ArtGravity has joined #gnucash
11:29:05 *** ChanServ sets mode: +v ArtGravity
11:29:47 <jralls> gjanssens The GTK_MAC_CFLAGS_OTHER defines MAC_INTEGRATION for binreloc to enable setting the bundle paths.
11:31:01 <gjanssens> jralls: ok, so the "GTK_" part is a bit misleading, but I suppose the variable name comes from Gtk on MacOS ?
11:32:08 *** calvinct has joined #gnucash
11:32:49 <jralls> No, it comes from https://github.com/Gnucash/gnucash/blob/maint/CMakeLists.txt#L440 but it depends on finding the gtk-mac-integration library.
11:33:02 *** Mechtilde has joined #gnucash
11:34:43 <jralls> That provides some C wrappers for the Objective-C bundle functions.
11:35:19 <gjanssens> Ah, no wonder my search for GTK_MAC_CFLAGS_OTHER didn't turn this up. It's a variable generated by pkg_config_modules
11:37:49 <gjanssens> It's a bit unfortunate this is combined in the gtk-mac-integration instead of something like glib-mac-integration
11:38:11 <gjanssens> To my mind gtk is very much gui related, where our core-utils are not
11:38:29 <gjanssens> On the other hand, perhaps on MacOS bundles only make sense for gui applications
11:38:57 <gjanssens> Regardless, I now understand that variable should remain
11:44:05 <gjanssens> Just so I understand it fully: the _CFLAGS_OTHER bit means it will parse the CFlags it finds and keeps only parameters that are not include directories, is that correct ?
11:48:02 <jralls> gjanssens, CORELE I don't remember. At the time of that commit it was only in that one place and it's not a standard CMake variable so it must be an error.
11:48:37 <gjanssens> I'll remove it
11:49:56 <jralls> Heh, I bet I know where it came from: I copied & pasted from the app-utils CMakeLists.txt then did the emacs equivalent of s/app/core/i. It's supposed to be if (APPLE).
11:50:03 *** mohave has quit IRC
11:50:42 *** fell_laptop has joined #gnucash
11:50:42 *** ChanServ sets mode: +o fell_laptop
11:51:19 <gjanssens> LOL
11:51:34 <gjanssens> Ok, I'll fix it that way...
11:53:17 <gjanssens> While in the area - I also notice the addition of OSX_EXTRA_LIBRARIES in core-utils
11:53:41 <gjanssens> Those are cocoa, security and carbon
11:53:57 <gjanssens> Are these used in core-utils ?
11:54:50 *** mohave has joined #gnucash
11:54:52 <gjanssens> Or what interests me more, should these be propagated as link libraries to other targets linking core-utils ?
11:55:12 <gjanssens> Or would they be private to core-utils ?
11:55:26 <jralls> I think that they can be private to core-utils.
11:55:38 <gjanssens> That was my guess also.
11:56:02 <gjanssens> I'll make them private in a separate commit, so it can easily be reverted if that turns out to be wrong.
11:56:55 <jralls> Do it in a PR and then I can test without needing to have it in history if it fails.
11:57:14 <gjanssens> Of course, that I would have done anyway
11:57:53 <gjanssens> This is a bit of a gray area for me though: when should a library be propagated ?
11:58:33 <jralls> Since you're doing the exercise I've seen several cmake-oriented blogs, as well as the Professional CMake book, advocate making everything private and then seeing what breaks and selectively changing things to INTERFACE as necessary to get the build to work.
11:59:00 <gjanssens> Oh, INTERFACE rather than PUBLIC even ?
11:59:35 <gjanssens> Well, I started refactoring all bindings out of the libgnucash tree
11:59:42 <gjanssens> I'm starting at the lowest level: core-utils
12:00:22 <gjanssens> So while I was heavily refactoring anyway, I thought why not improve our cmake quality while we're at it
12:01:11 <gjanssens> I'm currently fascinated by the power a proper use of PRIVATE and PUBLIC provide in target_xyz commands
12:01:23 <jralls> A library needs to be propagated if any of its symbols leak into the interface of its dependent target.
12:01:48 <gjanssens> Anyway, I have the Professional CMake book as well, so I can dig into it.
12:02:07 <gjanssens> I probably won't have time for *all* optimizations though :)
12:02:53 <jralls> Looks from the docs that INTERFACE is a "legacy" term replaced by "PUBLIC".
12:03:17 <gjanssens> Ok, so PUBLIC it will be
12:03:40 <jralls> The build system works. As long as it keeps working, incremental improvement is fine. Better, in fact.
12:05:17 <gjanssens> True. I'm trying to make my changes atomic and small.
12:10:42 <jralls> warlord: From https://bazaar.launchpad.net/~mdoyen/homebank/main/view/head:/src/rep-balance.c it looks like Homebank just writes reports as a list-mode GtkTreeView.
12:11:03 *** guak has joined #gnucash
12:15:15 <warlord> jralls, seriously? interesting. How do they do their graphics? And I wonder how users write reports (if at all)?
12:18:10 <jralls> I think no user-written reports. It's a small program compared to GnuCash, all in one source directory. Only a few reports: balance, budget, stats, time, and vehicle. Feel free to browse around the code yourself, but I don't think that there's anything there worth borrowing.
12:21:32 *** fabior has quit IRC
12:24:00 *** Agfarmer18 has joined #gnucash
12:24:43 <warlord> ok
12:30:30 *** storyjesse has joined #gnucash
12:34:19 *** calvinct has quit IRC
12:34:23 <gjanssens> jralls: this is my work so far: https://github.com/gjanssens/gnucash/tree/gnc-module-load-begone
12:35:05 <gjanssens> It moves all guile stuff in core-utils and libgnucash/scm to bindings/guile and cleans up a few dependencies
12:35:22 <gjanssens> Can you test if it still works on MacOS ?
12:35:36 <gjanssens> I won't have time left to work on it today so it's not urgent
12:36:08 <gjanssens> The next step I have planned is to also move the python bits from core-utils to bindings/python
12:36:30 <gjanssens> If all that continues to work well, I'll move up to engine and so on
12:37:01 <gjanssens> I don't think I will do app-utils until after you're ready with the options rewrite
12:37:18 <gjanssens> I think it would otherwise result in a difficult merge
12:38:56 <jralls> I'm not sure that we're ready to banish guile to bindings. There's way too much dependence on it in core code. It becomes a "binding" when main() no longer starts the guile interpreter and runs GnuCash inside it.
12:41:05 *** sbluhm has quit IRC
12:41:14 <gjanssens> jralls: "banish" is a bit too strong
12:41:26 <gjanssens> I'm not separating gnucash from guile
12:41:34 <gjanssens> I'm separating libgnucash from guile
12:41:59 <gjanssens> So for my goal, bindings/guile sits somewhere in between libgnucash and gnucash
12:42:13 <gjanssens> That is, gnucash will continue to require it, but libgnucash wouldn't
12:42:32 <gjanssens> That's one important milestone to port libgnucash to android or ios
12:43:11 <gjanssens> options is the biggest consumer of guile in libgnucash still, so that's an important one to get fix as well...
12:43:21 *** chris has quit IRC
12:43:33 <jralls> Oh? "Bindings" implies that the languages there are peripheral, a way to access libgnucash from those languages. That's true of Python, it's nowhere near true of Guile.
12:45:10 <jralls> It's not just options, either. Try `grep -rl SCM --include=*.[ch] libgnucash.
12:45:22 <gjanssens> I did :)
12:45:35 <gjanssens> I said "biggest" consumer
12:45:44 <gjanssens> Not the sole
12:46:35 <gjanssens> Parts of what that query returns will simply move to bindings/guile as well as they only are relevant in the context of guile.
12:47:48 *** Agfarmer18 has quit IRC
12:47:59 *** Agfarmer18 has joined #gnucash
12:48:01 <gjanssens> Other parts are only in the name like gnc_scm_log_warn, tough that function in itself doesn't touch any guile code
12:49:34 <gjanssens> Also I don't know how difficult it would really be to interface with libgnucash from a standalone guile script
12:49:55 <gjanssens> Currently that's almost impossible to discover as the guile bits are all over the place
12:50:18 <gjanssens> Grouping it all in one place should help a lot in figuring it out
12:50:24 <jralls> Right. Getting the plain-old-wrapper code separated from the "let's use SCM to avoid type issues or having to use void*" would be one stage. There's also some mixing of guile code that isn't used in libgnucash; that should move to gnucash.
12:51:27 <gjanssens> Do you have an example of that in mind ?
12:52:22 *** storyjesse has quit IRC
12:52:41 <jralls> Options, actually. The only reason for them to be in libgnucash is that the company address and counters are persisted in the book instead as scheme strings in GNC_APP_DATA.
12:54:52 <jralls> There's probably more in app-utils. By it's very name it belongs in gnucash, not libgnucash. But it has tendrils reaching into other parts of libgnucash that make pruning it out hard.
12:56:56 *** ChanServ sets mode: +qo warlord warlord
12:56:59 *** warlord sets mode: +o gncbot
12:59:54 *** mohave has quit IRC
13:03:26 <gjanssens> I tend to see that differently
13:04:04 <gjanssens> Options are there to support reports and I would like reports (the generation part) to live in libgnucash actually
13:04:36 <gjanssens> I would think it very useful to be able to generate a report directly from python bindings
13:05:37 <gjanssens> Displaying a report is another matter that clearly belongs in gnucash as it needs a graphical interface (at least if we stick with interactive reports)
13:06:16 <gjanssens> I don't want the reports scheme code in libgnucash, so this whole idea is much longer term
13:06:27 <jralls> That's possible now, one just must write all of the formatting and such in Python and use the engine interface to get the data.
13:06:58 <gjanssens> Of course, but not very ready-to-use
13:07:23 <gjanssens> A more concrete example: say my book has invoices for customers
13:07:47 <gjanssens> I can now open that report and print it for that customer.
13:07:55 <gjanssens> We used to have a pdf generator as well
13:08:36 <gjanssens> Now suppose gnucash is only part of a bigger workflow that's scripted (guile/python)
13:09:00 <jralls> Remember my long-term plan: Have a database, in memory if using the XML backend, and query it for display, edit, or report. Makes report generation much easier.
13:09:01 <gjanssens> And there's a trigger from script that says "ok, send customer y his invoice x"
13:09:43 <gjanssens> That's a perfect base, though I would like libgnucash to add a bit more convenience as well
13:10:32 <gjanssens> Of which predefined reports is one
13:10:46 <gjanssens> Got to go though...
13:10:59 <gjanssens> I don't think at this point it matters much
13:11:34 <gjanssens> Going for your original long-term plan is the first step in all future scenarios :)
13:11:49 <gjanssens> So if for now it's easier to move options to gnucash that's ok
13:12:06 <jralls> So let's have libgnucash/guile instead of bindings/guile, and separate that into wrapper-stuff and using-quile-where-we-shouldn't stuff.
13:12:07 <gjanssens> Reports are there as well and will be for quite a while
13:12:23 *** sbluhm has joined #gnucash
13:12:23 *** ChanServ sets mode: +v sbluhm
13:14:17 <jralls> Oh, as for options, the new code is completely separate, so better to move it sooner than later. It's easy to relocate now before I start modifying other code to work with it.
13:14:50 <jralls> But you need to go, so goodnight!
13:15:57 <gjanssens> Not gone yet :)
13:16:41 <gjanssens> I still don't see what's wrong with bindings/guile
13:16:51 <gjanssens> gnucash is just a consumer of these bindings
13:17:18 <gjanssens> Direct bindings from an external guile script is untested, but not necessarily impossible
13:17:19 <jralls> Because libgnucash is too.
13:17:44 <gjanssens> Libgnucash will no longer be. That's the whole point of my work
13:19:16 <jralls> Not there yet: https://github.com/gjanssens/gnucash/blob/gnc-module-load-begone/libgnucash/engine/CMakeLists.txt#L243
13:19:52 <jralls> https://github.com/gjanssens/gnucash/blob/gnc-module-load-begone/libgnucash/app-utils/CMakeLists.txt#L84
13:19:56 <gjanssens> Of course! So far I have only done core-utils
13:20:25 <gjanssens> I plan to work further down the dependency graph step by step...
13:20:54 <gjanssens> I'm not asking to merge yet...
13:21:44 <gjanssens> I just wanted you to test whether my OSX_EXTRA_LIBRARIES and friends shuffle didn't break things on MacOS
13:22:45 <gjanssens> Now I'm really off :)
13:22:47 <gjanssens> Bye
13:23:30 <jralls> Goodnight!
13:24:07 <jralls> But you based your branch on maint and it should be on master.
13:25:00 <jralls> It will conflict with the cmake modernization already on master.
13:26:54 <jralls> And we surely don't want to reorganize the directory structure in maint.
13:37:53 *** sbluhm has quit IRC
13:39:19 *** sbluhm has joined #gnucash
13:40:16 *** sbluhm has quit IRC
13:40:22 *** sbluhm has joined #gnucash
13:43:34 *** mohave has joined #gnucash
13:47:41 *** Agfarmer18 has quit IRC
13:47:52 *** sbluhm has quit IRC
13:51:36 *** sbluhm has joined #gnucash
13:51:36 *** ChanServ sets mode: +v sbluhm
13:52:25 *** calvinct has joined #gnucash
13:54:28 *** mohave has quit IRC
13:54:31 *** phoenix has joined #gnucash
13:56:06 *** sbluhm has quit IRC
14:05:38 *** frakturfreak has joined #gnucash
14:29:38 *** phoenix has quit IRC
14:30:08 *** mohave has joined #gnucash
14:40:53 *** mohave has quit IRC
14:44:23 *** RandomGuyOnIrc has quit IRC
14:44:27 *** daum has joined #gnucash
14:57:07 *** calvinct has quit IRC
15:01:33 *** calvinct has joined #gnucash
15:02:07 <jralls> @tell gjanssens I had to make a few changes to get it to build, noted in comments on your gnc-module-load-begone commits.
15:02:07 <gncbot> jralls: The operation succeeded.
15:02:40 *** calvinct has quit IRC
15:02:54 *** calvinct has joined #gnucash
15:10:13 *** calvinct has quit IRC
15:10:27 *** calvinct has joined #gnucash
15:12:06 *** sbluhm has joined #gnucash
15:20:52 *** calvinct has quit IRC
15:45:27 <gjanssens> jralls: I rechecked, but as far as I can see the branch *is* branched off of master. Parent commit is chris' merge of maint into master
15:45:27 <gncbot> gjanssens: Sent 43 minutes ago: <jralls> I had to make a few changes to get it to build, noted in comments on your gnc-module-load-begone commits.
15:50:58 *** bertbob has quit IRC
15:53:58 *** calvinct has joined #gnucash
15:56:47 *** oozer has quit IRC
16:05:59 <gjanssens> jralls: it's frustrating that on linux I don't need the extra link libraries you pointed out :(
16:06:17 <gjanssens> Makes it slightly harder to validate my changes across all platforms
16:07:26 <gjanssens> That is, in a clean build directory my branch compiles and links just fine all the way to the end without adding GLIB2_CFLAGS or Boost::locale
16:08:09 <gjanssens> OTOH I think it's better to explicitly set the link libraries on a module it uses by itself
16:10:10 <jralls> gjanssens, absolutely better to link and include what one uses where one uses it rather than to rely on other modules to provide them.
16:11:19 <jralls> gjanssens: If you look at it on github it says "159 commits ahead, 3 commits being Gnucash:maint". But maybe that's because maint is the default?
16:12:35 <gjanssens> Oh, that's probably because I haven't pushed maint and master to my github repo recently.
16:12:40 <gjanssens> Let me do that first
16:13:38 <jralls> Oh, I see that you've got chris's maint->master merge from yesterday in history so it must be off of master.
16:16:08 <gjanssens> Doesn't seem to make a differenct
16:16:42 <gjanssens> It's likely because there's no gnc-module-begone branch in Gnucash/gnucash that it compares with the default branch indeed
16:17:02 <jralls> Seems likely.
16:17:32 <jralls> And yes, using ${OSX_EXTRA_LIBRARIS} without the generator works fine.
16:18:02 <gjanssens> Ok, I'll use that then instead.
16:18:27 <jralls> About the branch name, do you intend to also get rid of gnc-modules as part of this exercise?
16:18:31 <gjanssens> And now to find a way to reproduce errors on overly private link libraries...
16:18:33 <gjanssens> Yep
16:18:42 <gjanssens> At least from libgnucash
16:19:16 <gjanssens> I would like that to become an ordinary shared library to link against
16:19:44 <gjanssens> I have some ideas to get there.
16:19:45 <jralls> It is if you want to use it that way.
16:19:55 <gjanssens> I know
16:19:55 <jralls> A lot of test programs do.
16:20:18 <gjanssens> I'm really in an entanglement effort
16:20:39 <gjanssens> Our scheme code is unclear on what it really wants wrt the gnc-module thing
16:20:52 <gjanssens> s/entanglement/untanglement/
16:21:18 <jralls> Actually "disentanglement". English can be obtuse sometimes.
16:21:51 <gjanssens> Tx. Hopefully the message was clear though
16:22:04 <jralls> Yes, both ways.
16:22:23 <gjanssens> My plan is to first get the wrappers in a clear and separate interface
16:22:39 <gjanssens> Then drop gnc-module use for anything related to that wrapper
16:23:10 <gjanssens> And finally make a real libgnucash.so to link against rather than the various sublibraries
16:23:39 <gjanssens> That would be accompanied by a libgnucash-guile.so for the guile wrappers
16:24:09 <gjanssens> And a gnucash.scm as main entry point for scheme code wanting to leverage libgnucash
16:24:29 <gjanssens> Similar to what's currently happening for the python wrapper
16:24:34 <jralls> In my c++options branch I want to make sure that everything works from scheme so I've already written and tested a stub wrapper. (load-exetension "libswig-gnc-optiondb" "scm_init_sw_gnc_optiondb_module") works a treat, though it's not as pretty as (load-module gnc-option).
16:25:10 <gjanssens> I have seen similar code elsewhere indeed
16:25:42 <jralls> No doubt, I copied it from somewhere. ;-)
16:26:17 <gjanssens> Because it's not that pretty, I came up with the idea of the single entry points libgnucash-guile.so and gnucash.scm
16:26:19 *** calvinct has quit IRC
16:26:39 <gjanssens> gnucash.scm would be the only file requiring the load-extension call
16:27:23 <gjanssens> All other scheme code can then simply (use-modules (gnucash)) or perhaps (use-modules (gnucash gnucash)), depending on how we structure the final install tree
16:27:25 <jralls> Right, (load-module gnucash) would execute whatever (load-extesion)s are necessary.
16:27:39 <gjanssens> Indeed
16:28:06 *** sbluhm has quit IRC
16:30:01 <gjanssens> jralls: do you have an idea why on linux the link libraries are picked up anyway even if they're private while they are not on MacOS ?
16:30:12 <gjanssens> would that be a clang vs gcc thing ?
16:30:29 <jralls> It
16:31:00 <jralls> It's possible, I suppose.
16:31:49 <jralls> I've gotten into trouble going the other way, where clang would link something that needed an explicit inclusion on Linux.
16:32:21 <gjanssens> Oh well, I'll have to experiment
16:32:34 <gjanssens> Later though. Now it's really time to say goodnight :)
16:32:55 <jralls> Goodnight!
16:34:22 *** gjanssens has quit IRC
16:37:18 *** Mechtilde has quit IRC
17:01:23 *** frakturfreak has quit IRC
17:05:41 *** pohly1 has quit IRC
17:09:06 *** fell_laptop has quit IRC
17:10:50 *** oozer has joined #gnucash
17:11:32 *** fell_laptop has joined #gnucash
17:11:32 *** ChanServ sets mode: +o fell_laptop
17:15:14 *** fell_laptop has quit IRC
17:15:22 *** fell_laptop has joined #gnucash
17:15:22 *** ChanServ sets mode: +o fell_laptop
17:20:59 *** bertbob has joined #gnucash
17:20:59 *** ChanServ sets mode: +v bertbob
17:45:23 *** jervin has joined #gnucash
17:54:28 *** oozer has quit IRC
18:05:42 *** mohave has joined #gnucash
18:20:15 *** mohave has quit IRC
18:31:12 *** ArtGravity has quit IRC
18:40:07 *** TommyT has joined #gnucash
18:40:07 *** ChanServ sets mode: +v TommyT
18:42:03 *** Aussie_matt has joined #gnucash
19:08:04 *** omnireq has quit IRC
19:22:04 *** TommyT has quit IRC
19:53:57 *** guak has quit IRC
20:03:27 *** omnireq has joined #gnucash
21:34:06 *** jervin has quit IRC
23:09:23 *** fell_laptop has quit IRC
23:11:08 *** omnireq_ has joined #gnucash
23:12:21 *** omnireq has quit IRC