On Thu, Sep 02, 2004 at 03:26:51PM -0400, David James wrote:
> PROBLEM:
>
> Currently, the process of building and installing bindings is quite complex.
>
> For example, here is how to build and test Subversion and the JavaHL
> bindings (from a source tarball):
> 1. ./configure [with some options]
> 2. make
> 3. make install
> 4. make check
> 5. make javahl
> 6. make javahl-tests
> 7. make install-javahl
> 8. make check-javahl
>
> The process of building and testing the SWIG bindings is also complex
> -- and it requires an entirely different set of commands from those
> required to build JavaHL.
>
> PROPOSED SOLUTION:
>
> If the user asks configure to build a binding, build it and test it
> with the rest of the Subversion.
>
> The build process (for all bindings) will now be:
> 1. ./configure [with some options]
> 2. make
> 3. make install
> 4. make check
>
> PROS
> - The new process is simpler than the old process (half as many lines!)
> - All bindings can be configured and built using the same process
> (only difference is a configure option!)
> - I generally expect an application to fully install after I type
> "./configure [with some options] && make && make install". Subversion
> will now operate as I expect.
> - Other advantages?
>
> CONS
> - The new process is different from the old process (Users will have
> to learn the new process)
> - Other disadvantages?
>
> Comments?
We already had this discussion. I made the Perl bindings behave exactly
this way. I got a lot of complaints. We decided to change it back.
A big part of the complaints was that the bindings have warnings. These
warnings come from external software (e.g. Perl defines functions that
conflict with C library function names). We have no effective way to
work around these warnings. There was a general feeling that our
mainline build should never have warnings (actually we have one or two
from Apache).
The other issue, is that it creates a problem for binary packagers.
Right now the build system integration of the Perl bindings don't
provide a good way to pass through the configuration options you usually
pass via the perl Makefile.PL call. A completely default install will
work fine, but binary packagers don't have that situation. So they need
to be able to ignore our build system integration. We may be able to
fix this issue, but I don't see a clean way to do that.
The Python bindings also don't install properly into Python. Someone
has to manually move them to their proper location after the install.
I'm not sure how easy it is to make our install put them in the proper
place.
In general, I'd love to see the bindings installed by default. But
there are a lot of things that have to happen before that happens. Some
of which are pretty unlikely to happen.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 3 00:12:11 2004