[Gnucash-changes] check_data_type, backend configuration and gettext

[Neil Williams]

On Tuesday 06 September 2005 6:08 pm, Derek Atkins wrote:

(Please read *all* of this one! I know it's long but hey, I wasted a lot of 
time on the getline code currently in CVS!)
:-))

> I guess I still don't understand why we don't just use the gmodule
> APIs. 

Umm, that would be because there's no mention of that in the docs or comments!
:-)

If it had been mentioned anywhere, I would have looked at it and saved myself 
quite a bit of work.
:-(

I'll swap over - it's a very similar API and it'll fit in very easily into the 
rest of the modifications I made to qof_load_backend_library().

> I'm certainly happy to have a platform-independent way of doing 
> it.  I'm less enthused about using .la files because of all the trouble
> they cause.

GModule still uses .la - it converts other suffixes to la in case of error 
first time around.

First of all g_module_open() tries to open file_name as a module. If that 
fails and file_name has the ".la"-suffix (and is a libtool archive) it tries 
to open the corresponding module. If that fails and it doesn't have the 
proper module suffix for the platform (G_MODULE_SUFFIX), this suffix will be 
appended and the corresponding module will be opened. If that fails and 
file_name doesn't have the ".la"-suffix, this suffix is appended and 
g_module_open() tries to open the corresponding module. If eventually that 
fails as well, NULL is returned.
http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html#g-module-open

> I must appolize.

(must get a spellchecker too ?!?!)  :-)

> Honestly, your emails are always so long and verbose 
> that I tend to read the first sentence or two of every paragraph and
> then skip the rest.  Otherwise I'd be spending about four hours a day
> just going through your emails.  ;)

Cheek! ;-)

Do you realise it can take me the best part of a morning to *compose* all 
those emails!! 

It's because in a former life I was a full-time proof-reader of legal / 
professional documents and did a fair bit of correspondence with government 
departments, national agencies and the like where typos where not acceptable! 
(That was in the days before WordPerfect had a decent spellchecker too!)

> This isn't meant as a complaint -- verbosity is really good in
> documentation.

:-) Is that why so many developers don't like writing docs!

> But when I'm trying to get through 300-500 messages 
> a day I tend to skim and that means I miss some things.  Mea Culpa.

It's OK - I'll try splitting emails so that different topics are in separate 
emails, maybe.

> > 1. implement some completely new method of determining the library name
> > from configure via $host?
>
> Well, that's what was done before and it seemed to be working.  Although
> honestly it would be nice we could could just pass the basename to the
> "open" call and let the system append the appropriate .so/.dylib/.dll

GModule will do that.

> >> The real lesson here:  Don't believe everything you read from GNU.
> >
> > Which systems, specifically, don't install .la files and would *not*
> > allow us to do so? These aren't someone else's .la files - these are
> > created from GnuCash source and installed using GnuCash Makefiles. Can't
> > we simply specify that these ARE needed for GnuCash? They are simple text
> > files as far as the installation process is concerned. I'd then do the
> > same for QOF.
>
> As I keep on saying, .la files cause lots of grief later on.

So you say, but I couldn't find any messages or webpages that document or 
complain about such grief. Do you have examples? What are we looking for / 
guarding against?

> Seriously, anytime any manual says "this is the one true way" step
> back a moment and ask yourself whether there are alternative ways,
> and what the downside of that "one true way" happens to be.  In this
> case, the problem is the rigidity of the .la file.  Once you use ONE
> .la file, everything else needs .la files, too.  And if it's expecting
> a .la file and doesn't find it then it will NOT fallback to the .so.

GModule should - at least at runtime. I would have implemented the same but 
I'm glad I don't have to reinvent that wheel as well.

> Here's a real-world example: On a build-host you happen to have the
> .la installed.  But it doesn't get installed onto the runtime.  Now
> you've got your .la and it's expecting the dependent library .la
> file..  and guess what?  It fails at runtime!  Users get confused as
> to why it's failing.  But it's working just fine for you on your
> development system, because you happen to have the right -devel
> library that has the .la file that it's looking for.  OOPS.

Isn't that just like any other problem with not installing required files? It 
would be the same if an EXTRA_DIST was missing etc. Can't we make the .la an 
EXTRA_DIST target? If we had used that XML file for backend config, that 
would have been a required file causing runtime errors.

It's down to the UI to make sensible error messages out of the problem. My 
code would have picked up this error and complained, GModule can do the same. 
It's a simple stat check.

> No, I really think gmodule is probably the best way to go, if we're
> unwilling to just use dlopen() ourself.  I *DO* want to move away from
> the load-from-scheme..  But that's going to take a lot of time and
> effort to fix.
>
> As for why we weren't using gmodule before --- it's a glib-2 thing,
> and only the g2 branch has been g2.  So we weren't "allowed" to depend
> on gmodule until g2.  But now we can, and IMHO we should just use that
> and be happy.

Consider it done.

(Just as soon as I can compile with -Werror!!!)
:-)

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050906/ed80854d/attachment.bin