[Gnucash-changes] check_data_type, backend configuration and gettext

Derek Atkins warlord at MIT.EDU
Tue Sep 6 09:38:13 EDT 2005


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

If there's a new platform out there that has a new form of dynamic
library I suspect that we'll have other problems than just the name
of the dynamic library extension that would require source changes.
E.g. Windows.

Right now there ARE only two..  .so and .dynlib ..  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.

The real lesson here:  Don't believe everything you read from GNU.

-derek

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

> On Monday 05 September 2005 3:28 pm, Derek Atkins wrote:
>> Umm, I don't think you can necessarily guarantee that the .la is
>> installed.
>
> ? I thought it was the recommended method for GNU systems ?
>
> http://www.gnu.org/software/libtool/manual.html#Finding-the-dlname
>
>> Indeed, most places do NOT install the .la, just the .so 
>> (or .dynlib) in the packaging system.
>
> Is there a problem in requiring that it *is* installed? All packaging systems 
> that I know will *allow* it to be installed, it may not be common practice 
> but it can be done - why else would GNU recommend it? 
>
> Isn't this a case of the packaging dictating to the source? If there is a 
> standard and recommended GNU method that is declared as "[t]he most 
> straightforward and flexible implementation" why should the source be forced 
> to support a less straightforward and less flexible method?
>
> What if a new system starts supporting GNU libtool and adds yet another suffix 
> to the possible list?
>
> You've asked me to put the demands of the source above those of the packaging 
> and now I'm confused.
> :-(
>
>> Also, I'm not sure I like the new API, unless "directory" is a "hint"
>> -- the ldopen() should have a set of directories it can search.  A
>> "search path".
>
> I'll double-check, I thought it did this already (internally). If not, I'll 
> add it - as recommended on the libtool page above.
>
> -- 
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.nosoftwarepatents.com/
> http://www.linux.codehelp.co.uk/
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

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


More information about the gnucash-devel mailing list