Library structure

Christian Stimming stimming at tuhh.de
Sat Jan 21 07:00:36 EST 2006


Am Samstag, 21. Januar 2006 02:01 schrieb Chris Shoemaker:
> > > > Ok, I think I've talked myself into this conclusion: Any application
> > > > initialization state that gets pulled from guile and used everywhere
> > > > else shouldn't be kept in gnucash-bin.  Instead, gnucash-bin can call
> > > > into libcore-utils and it can be stored there, where everyone else
> > > > can see it without depending on gnucash-bin.
> > >
> > > this is the right conclusion.
> >
> > Agreed.

Agreed, too. Note also that on Linux, a library is allowed to link to a binary 
executable and use symbols from there, but this is neither elegant nor 
portable at all. E.g. on windows this will absolutely not work. So a central 
extra library for those global states is indeed the correct solution.

Christian

> > > Quoting Chris Shoemaker <c.shoemaker at cox.net>:
> > >
> > > For example, imagine that I needed the
> > > authoritative share_path from inside the engine, and that I could only
> > > construct it in gnucash-bin, from the combination of build-time,
> > > environment and command-line input.
> >
> > Shouldn't we be using gnome_program_locate_file() for this?
> > E.G. gnc_gnome_locate_pixmap() et. al. in gnc_gnome_utils.c
>
> Probably.  I'll look into that when I get around to looking at what it
> was used for.
>
> -chris
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


More information about the gnucash-devel mailing list