[Gnucash-changes] check_data_type, backend configuration and gettext

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> On Tuesday 06 September 2005 2:38 pm, Derek Atkins wrote:
>> .la's are a programmer's nightmare.  IMHO they cause more problems
>> than they solve.  I don't care what GNU says -- the world is not
>> GNU.  There are other systems out there.
>
> Oh, come on, Derek! I wrote to you about this in August, specifically 
> mentioning the change from using the .so to the .la and you didn't mention 
> then it was a bad idea to use the .la! You sounded encouraging and happy that 
> I'd got it working:

I guess I still don't understand why we don't just use the gmodule
APIs.  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.

> Sun, 21 Aug 2005 09:01:31 -0400
>> > I've now got the gnc-backend-file library to open using the dlopen() 
>> > routines 
>> > and I've implemented a platform-independent way of accessing those 
>> > libraries 
>> > to replace Linus' direct call to the .so. I'm using the .la to provide the
>> > name of the shared library - .so on GNU/Linux, .dylib on OSX - and only 
>> > this 
>> > morning I successfully loaded the gnc backend in CashUtil using this 
>> > method. 
>> > 
>> nice!!!
>
> Did you miss my comment about using the .la or is there some other problem?

I must appolize.  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.  ;)

This isn't meant as a complaint -- verbosity is really good in
documentation.  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.

> I've mentioned the use of the .la in lots of emails since. Each time I've 
> referred to the new library build layout on this list I've used the .la: 
> libcashobjects.la and libgnc-backend-file.la. 
>
> Why the change now?

I figured you were just being lazy in your nomenclature.  ;)

> So where now?
>
> Do you want me to:
> 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

> 2. use the .la - as now or 
> 3. abandon the lot for a list of static const char* (which is what we had in 
> the first place)? I'm horribly confused.
> Or do you want:
> 4. Some combination of two/three of the above? Using one and falling back to 
> the old static char* method?

I'm not sure.  But gmodules might be the right solution, maybe?

  http://developer.gnome.org/doc/API/2.0/glib/glib-Dynamic-Loading-of-Modules.html

>> 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.

> I'm constantly being battered with the libtool manual from other sources - 
> it's a recommended method in the libtool manual and I simply cannot 
> understand the sudden change of heart.

Libtool sucks.  Unfortunately it sucks less than any other alternative.
But please don't drink the libtool coolaid.

> How can I know which bits of the standards, which bits of the manuals, I can 
> actually believe and use?

Ask?  ;)

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.

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.

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.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available