You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David James <st...@gmail.com> on 2004/09/02 19:26:51 UTC
[RFC] Streamlining Binding Installation
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?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by John Peacock <jp...@rowman.com>.
Erik Huelsmann wrote:
> True, but it was also decided that if the bindings were not as important as
> the rest of Subversion, that they should move to separate projects. If they
> were as important as the rest, the goal would be to set up nightly tests
> just as for the rest of the software.
Nightly tests are usually scripted, in which case who cares how many
steps it takes to build all of the bindings. And testing has very
little to do with most people (who assume the software is as good as
every says it is and just want to install it ;).
I'm mostly being a devil's advocate here; I think it is a good thing to
make the bindings easier to build (since I do both Python and Perl on
every machine where I install Subversion).
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Erik Huelsmann <e....@gmx.net>.
> --On Thursday, September 2, 2004 9:42 PM +0200 Erik Huelsmann
> <e....@gmx.net> wrote:
>
> > True, but it was also decided that if the bindings were not as important
> as
> > the rest of Subversion, that they should move to separate projects. If
> they
> > were as important as the rest, the goal would be to set up nightly tests
> > just as for the rest of the software.
>
> I thought we decided that they *were* important: hence, they are remaining
> in
> the main tree. -- justin
Yes, we did (which I strongly agree with). With it comes the responsibility
for QA and stability. So that is why I think why its good to make it easy to
build and test them.
Preferrably without installing them first, but then again, you already
pointed out the problems with that.
bye,
Erik.
--
NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> I don't do builds where the source-tree and build-tree are different,
> but I'm fairly confident that if I *was* to do this, the build-tree
> would lack the non-SWIG-generated Python modules (the 'svn' stuff, not
> the 'libsvn' stuff).
I built JavaHL with different build and source trees, and it worked
beautifully. I haven't tried it with SWIG yet.
> Also, the SWIG-generated Python modules need to be built into into a
> 'libsvn' subdirectory (preferably a sibling of the 'svn' subdirectory)
> so that they can be referenced as the 'libsvn' module.
Ok, looks doable.
> I think once those two things are solved, a test framework could add
> the common parent directory of the build-tree 'svn' and 'libsvn'
> directories to sys.path (at the head of the list, of course, to
> override any installed bindings), and then could import those modules
> and test exactly as you would if 'svn' and 'libsvn' were installed.
Beautiful. That's exactly what Perl does (they create a 'blib'
directory and install everything there to start, then copy everything
out to the main install directory)
> Oh! And also, ideally, build-tree C-based modules would link against
> build-tree Subversion libraries (not the installed ones).
That's doable. Would we need to relink everything to do the main
installation? If we did have to relink everything, would that be a
problem?
> Hello? David? Are you still around? Have you run for the hills yet?
> :-)
I'm still on board :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by "C. Michael Pilato" <cm...@collab.net>.
David James <st...@gmail.com> writes:
> > > I think the only caveat is that you might have to install it first
> > > before running tests. There might be some creative ways around that,
> > > but libtool is going to make it more difficult than it has to be.
> > That's the caveat that keep me down. We need to be able to do
> > in-place (that is, in-build-dir) testing before folks install.
> I agree. I'd be willing to work on this issue. What issues need to be
> worked out before I begin?
I don't do builds where the source-tree and build-tree are different,
but I'm fairly confident that if I *was* to do this, the build-tree
would lack the non-SWIG-generated Python modules (the 'svn' stuff, not
the 'libsvn' stuff).
Also, the SWIG-generated Python modules need to be built into into a
'libsvn' subdirectory (preferably a sibling of the 'svn' subdirectory)
so that they can be referenced as the 'libsvn' module.
I think once those two things are solved, a test framework could add
the common parent directory of the build-tree 'svn' and 'libsvn'
directories to sys.path (at the head of the list, of course, to
override any installed bindings), and then could import those modules
and test exactly as you would if 'svn' and 'libsvn' were installed.
Oh! And also, ideally, build-tree C-based modules would link against
build-tree Subversion libraries (not the installed ones).
Hello? David? Are you still around? Have you run for the hills yet?
:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> > I think the only caveat is that you might have to install it first
> > before running tests. There might be some creative ways around that,
> > but libtool is going to make it more difficult than it has to be.
> That's the caveat that keep me down. We need to be able to do
> in-place (that is, in-build-dir) testing before folks install.
I agree. I'd be willing to work on this issue. What issues need to be
worked out before I begin?
Cheers,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 4:40 PM -0400 David James <st...@gmail.com>
wrote:
> There's got to be a better way to do this. Perl manages to test its XS
> modules in the build directory (i.e. before installing them). I think
> the trick is that Perl uses relative paths. (So these stay consistent
> after installation.)
Perl doesn't use libtool. Furthermore, libtool requires absolute paths
anyway: it'll choke if you give it a relative -rpath option. (Relative paths
just aren't portable.) -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> No, the trick is that Perl specifically prepends the search for where to
> find modules with blib/lib (pure Perl code) and blib/arch (compiled XS).
> The issue is that _only_ Perl does this; other code uses the OS
> library load routines which can sometimes be fooled (i.e. setting
> environment variables), but not always.
On Linux you can set LD_LIBRARY_PATH. Is there a general solution to
this problem? What search terms should I use while researching this
issue?
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by John Peacock <jp...@rowman.com>.
David James wrote:
> There's got to be a better way to do this. Perl manages to test its XS
> modules in the build directory (i.e. before installing them). I think
> the trick is that Perl uses relative paths. (So these stay consistent
> after installation.)
No, the trick is that Perl specifically prepends the search for where to
find modules with blib/lib (pure Perl code) and blib/arch (compiled XS).
The issue is that _only_ Perl does this; other code uses the OS
library load routines which can sometimes be fooled (i.e. setting
environment variables), but not always.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> Python, Java, and Perl are going to require an even greater level of trickery.
> I'll note that httpd's test suite is a standalone suite that requires
> installation. I just think we're going to end up with the same solution (by
> and large) for our bindings. -- justin
There's got to be a better way to do this. Perl manages to test its XS
modules in the build directory (i.e. before installing them). I think
the trick is that Perl uses relative paths. (So these stay consistent
after installation.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Max Bowsher <ma...@ukf.net>.
Toby Johnson wrote:
> Ben Reser wrote:
>
>> The Perl bindings test in tree just fine already. It even works on OS
>> X. :)
>>
>>
> Not meaning to hijack the thread, but where do Perl bindings on win32
> stand? Haven't seen anything regarding those on the list lately.
Then don't hijack the thread :-)
Seriously, start a new one! It's not hard, and a better subject is more
likely to grab the eye of people equipped to answer your question!
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Toby Johnson <to...@etjohnson.us>.
Ben Reser wrote:
>The Perl bindings test in tree just fine already. It even works on OS
>X. :)
>
>
Not meaning to hijack the thread, but where do Perl bindings on win32
stand? Haven't seen anything regarding those on the list lately.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 02, 2004 at 01:36:44PM -0700, Justin Erenkrantz wrote:
> Without tossing libtool, I don't think so.
>
> The only way the regular tests work is that they call out to our svn*
> executables which happen to be libtool shell scripts that tweak the
> environment and binaries (!) that trick the system into thinking it's
> loading from the installed directory. (Take a look and you'll see what I
> mean.) And note that the in-place testing we do now doesn't necessarily
> work on all OSes either. libtool doesn't know how to trick Mac OS X into
> ignoring the installed libraries - so test cases always fail for me until I
> install.
>
> Python, Java, and Perl are going to require an even greater level of
> trickery. I'll note that httpd's test suite is a standalone suite that
> requires installation. I just think we're going to end up with the same
> solution (by and large) for our bindings.
The Perl bindings test in tree just fine already. It even works on OS
X. :)
Yes we're not using libtool. But APR does provide us a way to find out
how to ask for libs on a different path:
apr-config --shlib-path-var
When I tightened up the integration of the Perl bindings a while back I
added a variable for configure the replace to get this:
@SVN_APR_SHLIB_PATH_VAR@
So I don't think it's necessary to ditch libtool to get this
functionality. We just have to use some APR functionality and ignore
the libtool functionality that doesn't work right.
--
Ben Reser <be...@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
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 3:25 PM -0500 "C. Michael Pilato"
<cm...@collab.net> wrote:
> That's the caveat that keep me down. We need to be able to do
> in-place (that is, in-build-dir) testing before folks install.
Without tossing libtool, I don't think so.
The only way the regular tests work is that they call out to our svn*
executables which happen to be libtool shell scripts that tweak the
environment and binaries (!) that trick the system into thinking it's loading
from the installed directory. (Take a look and you'll see what I mean.) And
note that the in-place testing we do now doesn't necessarily work on all OSes
either. libtool doesn't know how to trick Mac OS X into ignoring the
installed libraries - so test cases always fail for me until I install.
Python, Java, and Perl are going to require an even greater level of trickery.
I'll note that httpd's test suite is a standalone suite that requires
installation. I just think we're going to end up with the same solution (by
and large) for our bindings. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Jani Averbach <ja...@jaa.iki.fi>.
On 2004-09-02 15:25-0500, C. Michael Pilato wrote:
> Justin Erenkrantz <ju...@erenkrantz.com> writes:
>
> > I think the only caveat is that you might have to install it first
> > before running tests. There might be some creative ways around that,
> > but libtool is going to make it more difficult than it has to be.
>
> That's the caveat that keep me down. We need to be able to do
> in-place (that is, in-build-dir) testing before folks install.
Yes. If we could same time implement testing (easily) against the
installed system, that would be also very handy.
BR, Jani
--
Jani Averbach
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by "C. Michael Pilato" <cm...@collab.net>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> I think the only caveat is that you might have to install it first
> before running tests. There might be some creative ways around that,
> but libtool is going to make it more difficult than it has to be.
That's the caveat that keep me down. We need to be able to do
in-place (that is, in-build-dir) testing before folks install.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 2:57 PM -0500 "C. Michael Pilato"
<cm...@collab.net> wrote:
> Personally, I just want to solve the bindings build problems that
> prevent me from writing unit tests for the Python bindings. I'd
> *love* to use such tests to track API coverage and such.
Do you have an example?
I think the only caveat is that you might have to install it first before
running tests. There might be some creative ways around that, but libtool is
going to make it more difficult than it has to be. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by "C. Michael Pilato" <cm...@collab.net>.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> --On Thursday, September 2, 2004 9:42 PM +0200 Erik Huelsmann
> <e....@gmx.net> wrote:
>
> > True, but it was also decided that if the bindings were not as
> > important as the rest of Subversion, that they should move to
> > separate projects. If they were as important as the rest, the
> > goal would be to set up nightly tests just as for the rest of the
> > software.
>
> I thought we decided that they *were* important: hence, they are
> remaining in the main tree. -- justin
Both are correct. We decided that the bindings were important enough
to maintain alongside the rest of the code, and not important enough
to significantly impact releases.
Personally, I just want to solve the bindings build problems that
prevent me from writing unit tests for the Python bindings. I'd
*love* to use such tests to track API coverage and such.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 9:42 PM +0200 Erik Huelsmann
<e....@gmx.net> wrote:
> True, but it was also decided that if the bindings were not as important as
> the rest of Subversion, that they should move to separate projects. If they
> were as important as the rest, the goal would be to set up nightly tests
> just as for the rest of the software.
I thought we decided that they *were* important: hence, they are remaining in
the main tree. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Erik Huelsmann <e....@gmx.net>.
> David James wrote:
>
> > CONS
> > - The new process is different from the old process (Users will have
> > to learn the new process)
>
> <bb>So what...big deal...</bb>
>
> > - Other disadvantages?
>
> The big one being that, until recently, the bindings were not as mature
> and more likely to fail to build correctly.
True, but it was also decided that if the bindings were not as important as
the rest of Subversion, that they should move to separate projects. If they
were as important as the rest, the goal would be to set up nightly tests
just as for the rest of the software.
I'm glad that this proposal is a step in the direction of integration and
QA.
bye,
Erik.
--
Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR*
Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> > - Other disadvantages?
> The big one being that, until recently, the bindings were not as mature
> and more likely to fail to build correctly. By making a "big tent"
> makefile, you are causing the more stable core build to rely on less
> stable features. Granted, the user has to explicitely ask for that pain
> during configure. At the very least, _no_ bindings should be default
> specifically unless requested.
That's the current plan. If the user asks for the bindings, compile
them. Otherwise, don't :)
Cheers,
David
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> I'd extend this slightly:
>
> Each language is a tri-state setting.
> Default = status quo (quite nice when testing - I may only reconfigure my
> subversion trunk WC quite rarely, but whether I want the bindings built
> changes more often.)
>
> --enable-foo : Raise an error during configure if necessary external bits to
> build foo bindings are not found. Include the foo bindings build in "make".
>
> --disable-foo : Don't look for foo at all.
Yes, that's exactly what I meant!
Thanks,
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Max Bowsher <ma...@ukf.net>.
David James wrote:
> Here's a condensed version of my original proposal:
> 1. By default, don't install any bindings (because not everyone has
> Java, Python, or Perl)
> 2. If they ask to install the bindings (in the configure script), then
> build and install them with the rest of subversion!
I'd extend this slightly:
Each language is a tri-state setting.
Default = status quo (quite nice when testing - I may only reconfigure my
subversion trunk WC quite rarely, but whether I want the bindings built
changes more often.)
--enable-foo : Raise an error during configure if necessary external bits to
build foo bindings are not found. Include the foo bindings build in "make".
--disable-foo : Don't look for foo at all.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Ben Reser <be...@reser.org>.
On Thu, Sep 02, 2004 at 01:12:35PM -0700, Justin Erenkrantz wrote:
> Part of the problem is that the bindings don't build everywhere just yet.
>
> As I mentioned before, Perl doesn't work for me at all. And, since they
> don't use the standard build system, I can't do much to help as they use
> some goofy Perl-only build system that is rather buggy (ExtMaker or
> something).
That's not really a fair depiction of your problem with the Perl
bindings. You don't *HAVE* to use a VPATH build. You want to. Working
with you a while back we worked out most of the problems. We're down to
the man pages picking up the relative paths.
The perl build system is not "rather buggy" it works for the vast
majority of people. There are of course exceptions. But you know there
are even certain cases where the mainline build system has failed for
more obscure setups.
The fact is, we can't imagine every possible obscure situation, until
someone tries a particular setup we won't know how the build system
works with it.
So please don't exagerate your problem. Yes I will get back to it. I
just have been busy with other things.
--
Ben Reser <be...@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
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 4:00 PM -0400 David James <st...@gmail.com>
wrote:
> Here's a condensed version of my original proposal:
> 1. By default, don't install any bindings (because not everyone has
> Java, Python, or Perl)
> 2. If they ask to install the bindings (in the configure script), then
> build and install them with the rest of subversion!
If SWIG supports the language, we'll automatically enable the bindings for
that language. So, lots of people will get these options enabled without
asking first. (Yes, we could change that, but I don't think we should.)
Part of the problem is that the bindings don't build everywhere just yet.
As I mentioned before, Perl doesn't work for me at all. And, since they don't
use the standard build system, I can't do much to help as they use some goofy
Perl-only build system that is rather buggy (ExtMaker or something).
JavaHL is only beginning to get wide enough usage (outside of me and Patrick)
to where we're getting useful feedback on the build system. It's probably
close enough to turn it on for everyone if we detect the right tools.
By and large (I'm not sure what C-Mike is seeing), the Python builds are going
to be the best supported because they've been in the tree the longest.
I'm not against it, but turning on an option when we know some don't build and
only one or two people know how to fix it isn't goodness. My hunch is the
1.2.0 release (i.e. our next major release) can have this on by default. We
can shoot for having the build kinks worked out by then. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by David James <st...@gmail.com>.
> > > Heh --- call me cynical, but I believe that if you build *all* bindings
> > by
> > > default, they're much more likely to be kept up-to-date ;-).
> > Before breser pipes up, I'll point out that some people don't have/won't
> > load Java...
> Yes, but we can start setting up unit tests at nightly intervals easier than
> it is now. After that breakage can be detected easier (I believe).
Here's a condensed version of my original proposal:
1. By default, don't install any bindings (because not everyone has
Java, Python, or Perl)
2. If they ask to install the bindings (in the configure script), then
build and install them with the rest of subversion!
As Erik mentioned, this change will make setting up the unit tests
easier, because the binding unit tests will be integrated with the
rest of the test suite. Once we have those automated unit tests up and
running (and e-mailing the svn-breakage list), everyone will know when
the bindings break.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Erik Huelsmann <e....@gmx.net>.
> Greg Wilson wrote:
>
> > Heh --- call me cynical, but I believe that if you build *all* bindings
> by
> > default, they're much more likely to be kept up-to-date ;-).
>
> Before breser pipes up, I'll point out that some people don't have/won't
> load Java...
Yes, but we can start setting up unit tests at nightly intervals easier than
it is now. After that breakage can be detected easier (I believe).
bye,
Erik.
--
NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien!
1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by John Peacock <jp...@rowman.com>.
Greg Wilson wrote:
> Heh --- call me cynical, but I believe that if you build *all* bindings by
> default, they're much more likely to be kept up-to-date ;-).
Before breser pipes up, I'll point out that some people don't have/won't
load Java...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Greg Wilson <gv...@cs.toronto.edu>.
> On Thu, 2 Sep 2004, John Peacock wrote:
> The big [disadvantage] being that, until recently, the bindings were not
> as mature and more likely to fail to build correctly. By making a "big
> tent" makefile, you are causing the more stable core build to rely on
> less stable features. Granted, the user has to explicitely ask for that
> pain during configure. At the very least, _no_ bindings should be
> default specifically unless requested.
Heh --- call me cynical, but I believe that if you build *all* bindings by
default, they're much more likely to be kept up-to-date ;-).
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Thursday, September 2, 2004 3:33 PM -0400 John Peacock
<jp...@rowman.com> wrote:
> The big one being that, until recently, the bindings were not as mature and
> more likely to fail to build correctly. By making a "big tent" makefile,
FWIW, the Perl bindings still don't build in a VPATH setup (source dir !=
build dir). Ben Reser took a quick look at it, but he got into a twisty maze
of Perl wonkiness. I've got an uncompleted patch from him that gets perl
fairly close to building, but isn't complete (some minor local mods on top of
his).
I'm not sure if Ben plans to pick it up or not... -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by John Peacock <jp...@rowman.com>.
David James wrote:
> CONS
> - The new process is different from the old process (Users will have
> to learn the new process)
<bb>So what...big deal...</bb>
> - Other disadvantages?
The big one being that, until recently, the bindings were not as mature
and more likely to fail to build correctly. By making a "big tent"
makefile, you are causing the more stable core build to rely on less
stable features. Granted, the user has to explicitely ask for that pain
during configure. At the very least, _no_ bindings should be default
specifically unless requested.
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Max Bowsher <ma...@ukf.net>.
Ben Reser wrote:
> 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.
Now, is that a bug, or a feature? :-)
I rather like the status quo, and use a .pth (path definition) file to point
python to the bindings. It means that if I have multiple versions of svn
installed, the bindings for each are clearly associated. That said, if
python-prefix == svn-prefix, we probably should be installing directly to
python's libdir. But *only* if that condition is met - otherwise, keep the
status quo.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [RFC] Streamlining Binding Installation
Posted by Ben Reser <be...@reser.org>.
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 <be...@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