backend configuration and gettext
linux at codehelp.co.uk
Tue Sep 6 10:41:20 EDT 2005
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.
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050906/ca392721/attachment.bin
More information about the gnucash-devel