On Tue, 2004-03-30 at 04:49, Justin Erenkrantz wrote:
> This would add a new build and run-time dependency that I think we have to be
> very careful about handling. I really wish this could be made optional rather
> than being a mandatory requirement. As an aside, we would have to disable
> static linking if we import gettext as LGPL forbids any static binaries
> created with LGPL functionality. (Hmm, we'd have to do the same for neon -
> are we?)
That's not necessarily our problem, as long as we don't ourselves
distribute the static binary. If a user wishes to create a static
binary and use it without distributing it, the LGPL restrictions on
distributing static binaries don't come into play.
Also, the LGPL does not forbid static binaries; it just places some
conditions on their distribution. Those conditions are mildly onerous
for a proprietary product--they involve distributing linkable object
files--but not terribly onerous for a non-GPL free software project.
One way of complying would be to make sure that the directory or page
you distribute the static binary from also contains the source code used
to create that binary, including the external dependencies.
> * subversion/*.c: We do not protect includes of svn_private_config.h as it is
> always available (even on Win32). You are also using the incorrect syntax (<>
> vs "")
This has been a long-standing point of disagreement between me and the
svn source code base. As I understand it, the difference between
#include "foo" and #include <foo> is that the former searches the source
code file's directory before the include path, and that's it. By
implication, the only files we should be including with "foo" are the
directory-private headers like wc.h. But we seem to include all of our
own headers with "foo".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 18:36:30 2004