[Gnucash-changes] check_data_type, backend configuration and gettext

[Neil Williams]

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:

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'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?

> Right now there ARE only two..  .so and .dynlib

.dylib (no 'n')

> ..  Eventually there 
> may be a third, .dll.  Not too many to keep track of ourselves,
> IMHO.  And this way we can work around the .la brokenness.

So where now?

Do you want me to:
1. implement some completely new method of determining the library name from 
configure via $host?
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?

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

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.

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

-- 

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/ca392721/attachment.bin