Re: rename troublesome ltdl apis [libtool--devo--1.0--patch-275]

[Gary V. Vaughan]

Hallo Ralf,

Ralf Wildenhues wrote:
>>* Gary V. Vaughan wrote on Sun, Sep 18, 2005 at 11:52:06AM CEST:
>>
>>>Only the same arguments we both put forth for changing the name of
>>>lt_dlcaller_register -- forced to change function footprint to avoid
>>>problems with other clients' modules, which in turn suggests a good
>>>reason to rename said functions to force a hard compilation failure if
>>>the user doesn't upgrade the caller's semantics to match the new APIs.
> 
> Still, there is no need to rename all of the functions, unless all of
> their semantics have changed.  One rename to force compilation failure
> is sufficient, if the users can adapt to the rest by a source-code
> compatible change.

Hmmm.. that's true.  For just this patch (lets discuss 277 separately,
so I can think carefully about one issue at once), the semantics have
in fact not changed, so I'm okay with leaving the get/set function
names unchanged.  I'll repost the patch presently.

> Gary, people will simply NOT USE libltdl-2.0 if they cannot gradually
> update to it easily.  Getting package authors to update is difficult
> enough if they have to adapt at all, with distribution people it is
> much more difficult so.

To be honest, m4 is the only package I know of (beyond stuff I've
written myself) that uses these APIs, although they have been around
for a while so there's been plenty of time for people to have quietly
taken advantage of them.

> And no: do not change lt_ptr nor its advocation, up until the day that
> we add support for systems where
>   sizeof(void *) != sizeof(void (*)(void)).
> Otherwise, there is no need.

Already agreed to that in the last round of discussion :-)

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

signature.asc
Description: OpenPGP digital signature