On 7/8/06, Dominik Vogt <[EMAIL PROTECTED]> wrote:
On Sat, Jul 08, 2006 at 07:58:46PM +0100, seventh guardian wrote:
> Hi.
>
> What do you think of separating the compatibility code (replacement
> functions) from libfvwm?
>
> Functions like strncasecmp or strdup are spread all over the code. For
> systems that do not have them availiable, libfvwm is responsible for
> providing them. But the question is, should this be the responsibility
> of libfvwm? Or should fvwmlib have only fvwm related functions and
> leave the system compatibility functions to another lib?
>
> What I think:
>
> Compatibility functions should be separated from libfvwm, as they "are
> not part" of fvwm. They should be linked automatically if needed, but
> should remain invisible for the libfvwm code. Particulary, the
> replacement function definitions should be in config.h if needed,
> instead of fvwmlib.h. It would help on keeping the code clean, as the
> replacement functions should be stable now, and may even be kept "as
> is" to fvwm3.0 (?).
>
> I believe (supported by local tests) that this is possible to do
> without too much fuss or without introducing any bugs.
>
> On the other hand, it may be prudent to wait before the 2.5.17 release.
I don't get the point of doing that. Whats the difference between
having them in libfvwm.a or a different lib?
Instead of a big monolythic library we have two libraries: one with
actual fvwm code, and the other with compatibility code (used only if
needed). It's just a matter of modularity, as it would keep different
things separate.
But I agree that there's no big difference at the end, as things would
end up linked against each other in the final executable..
Renato
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt, [EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEsCw8meSprTOr4tgRAsK8AJ9ddvhmx9n/Mt5ZintUk9L6Ba4eHgCg4svj
Ik22tDxOKU+hr8BVro+n2s8=
=3iJw
-----END PGP SIGNATURE-----
