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 Summers <da...@summersoft.fay.ar.us> on 2004/07/08 03:30:18 UTC

libsvn_swig_py.so not being installed

My RPM build broke trying to install the /usr/lib/libsvn_swig_py.so file 
(it couldn't find it).  It was working a couple of weeks ago the last time 
I tried building the RPM for trunk.

On #svn IRC channel, breser helped me figure it out.  The "make 
install-swig-py-lib" is not being called (probably because it is not any 
more dependent on the "make install-swig-py".

While I can work around it for the moment by adding "make 
install-swig-py-lib", breser and I both think that the best fix is to fix 
the dependency so it is again installed by default when "make install-swig-py"
is called, but neither of us are familiar enough with the build system to
effect that change.  Alternately, the INSTALL should be fixed to tell the 
builder to "make install-swig-py-lib".

Help?  (Probably rey4?)

   Thanks!

-- 
David Wayne Summers          "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us   PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  C0 E0 4F 50 DD A9 B6 2B  60 A1 31 7E D2 28 6D A8 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed [PATCH]

Posted by Ben Reser <be...@reser.org>.
On Thu, Jul 08, 2004 at 06:06:18PM -0400, Russell Yanofsky wrote:
> The last patch created a circular dependency in the makefile. A new patch is
> attached which avoids this.
> 
> Log Message:
> 
> Build generator fix. Make install targets in generated makefile have
> explicit dependencies on library install targets. So for example,
> make the "install-bin" target depend on the "install-lib"
> target because one or more of the installed files in "install-bin"
> depends on one or more libraries installed by "install-lib"
> 
> * build/generator/gen_make.py
>   (Generator.write):
>     output install dependencies from graph
> 

Committed in r10212, it works well here.

-- 
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

FIXED Re: libsvn_swig_py.so not being installed [PATCH]

Posted by David Summers <da...@summersoft.fay.ar.us>.
The latest set of commits to the build system fixes the problem I was 
having trying to install libsvn_swig_py.so.

   Thanks for fixing it.

   - David

On Thu, 8 Jul 2004, Russell Yanofsky wrote:

> The last patch created a circular dependency in the makefile. A new patch is
> attached which avoids this.
> 
> Log Message:
> 
> Build generator fix. Make install targets in generated makefile have
> explicit dependencies on library install targets. So for example,
> make the "install-bin" target depend on the "install-lib"
> target because one or more of the installed files in "install-bin"
> depends on one or more libraries installed by "install-lib"
> 
> * build/generator/gen_make.py
>   (Generator.write):
>     output install dependencies from graph
> 

-- 
David Wayne Summers          "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us   PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint =  C0 E0 4F 50 DD A9 B6 2B  60 A1 31 7E D2 28 6D A8 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed [PATCH]

Posted by Russell Yanofsky <re...@columbia.edu>.
The last patch created a circular dependency in the makefile. A new patch is
attached which avoids this.

Log Message:

Build generator fix. Make install targets in generated makefile have
explicit dependencies on library install targets. So for example,
make the "install-bin" target depend on the "install-lib"
target because one or more of the installed files in "install-bin"
depends on one or more libraries installed by "install-lib"

* build/generator/gen_make.py
  (Generator.write):
    output install dependencies from graph

Re: libsvn_swig_py.so not being installed [PATCH]

Posted by Russell Yanofsky <re...@columbia.edu>.
Russell Yanofsky wrote:
> Justin Erenkrantz wrote:
>> install-swig-py-lib has never depended on install-swig-py.  Every
>> time I brought that up before, someone complained that it should be
>> separate.  So, this isn't recent.  It'd be nice to fix it though.  --
>
> I'm pretty sure Justin is right, because AFAIK the make generator has
> never had any mechanism to make one install target depend on another.
> I can add one though.

A possible fix is attached. Please let me know if it is ok. It works in a
general way, affecting not only the swig install targets, but all install
targets that depend on libraries.

Log Message:

Build generator fix. Make install targets in generated makefile have
explicit dependencies on library install targets. So for example,
make the "install-bin" target depend on the "install-lib"
target because one or more of the installed files in "install-bin"
depends on one or more libraries installed by "install-lib"

* build/generator/gen_make.py
  (Generator.write):
    output install dependencies from graph

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Justin Erenkrantz wrote:
> --On Wednesday, July 7, 2004 10:30 PM -0500 David Summers
> <da...@summersoft.fay.ar.us> wrote:
>
>> On #svn IRC channel, breser helped me figure it out.  The "make
>> install-swig-py-lib" is not being called (probably because it is not
>> any more dependent on the "make install-swig-py".
>
> install-swig-py-lib has never depended on install-swig-py.  Every
> time I brought that up before, someone complained that it should be
> separate.  So, this isn't recent.  It'd be nice to fix it though.  --

I'm pretty sure Justin is right, because AFAIK the make generator has never
had any mechanism to make one install target depend on another. I can add
one though.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> On Fri, Jul 09, 2004 at 05:28:09PM -0700, Ben Reser wrote:
>> On Thu, Jul 08, 2004 at 06:05:11PM +0100, Max Bowsher wrote:
>>>
http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-November/012288.html
>>>
>>> says:
>>>
>>>> Proposal:
>>>> ---------
>>> ...
>>>> 7. The Runtime directory
>>>>
>>>> The current Runtime directory, libtool, and all associated files
>>>> will be deleted and no longer used.
>>>
>>> This proposal seems to have been well-received.
>>
>> This is probably a good thing.  The number one problem people have
>> installing SWIG bindings is runtime version mismatches.  This would
>> avoid that problem entirely.
>
> Actually this is already implemented:
> http://www.swig.org/Doc1.3/Modules.html

Most of it, but not parts 4, 5, or 7. Part 7 is the part Max quoted and the
part
relevent to what I was saying before.

> clkao has pointed out that our current Perl bindings fail when trying
> to install against multiple versions of Perl on the same machine.
> Linking the runtime into the _Core.so ought to help eliminate that.

Linking the runtime into the core module sounds like a pretty good idea
since the runtime code is actually in there already, we'd just have to drop
the -noruntime parameter to swig to enable it. I don't know why I never
thought of that before...

But just to be clear, we had been talking about linking the runtime into
libsvn_swig_perl-1.la, not _Core.so, which wouldn't help with multiple
versions of perl.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Ben Reser <be...@reser.org>.
On Fri, Jul 09, 2004 at 05:28:09PM -0700, Ben Reser wrote:
> On Thu, Jul 08, 2004 at 06:05:11PM +0100, Max Bowsher wrote:
> > http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-November/012288.html
> > 
> > says:
> > 
> > | Proposal:
> > | ---------
> > ...
> > | 7. The Runtime directory
> > | 
> > | The current Runtime directory, libtool, and all associated files will
> > | be deleted and no longer used.
> > 
> > This proposal seems to have been well-received.
> 
> This is probably a good thing.  The number one problem people have
> installing SWIG bindings is runtime version mismatches.  This would
> avoid that problem entirely.

Actually this is already implemented:
http://www.swig.org/Doc1.3/Modules.html

clkao has pointed out that our current Perl bindings fail when trying to
install against multiple versions of Perl on the same machine.  Linking
the runtime into the _Core.so ought to help eliminate that.  

Something to mess with after we branch for 1.1.

-- 
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: libsvn_swig_py.so not being installed

Posted by Ben Reser <be...@reser.org>.
On Thu, Jul 08, 2004 at 06:05:11PM +0100, Max Bowsher wrote:
> http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-November/012288.html
> 
> says:
> 
> | Proposal:
> | ---------
> ...
> | 7. The Runtime directory
> | 
> | The current Runtime directory, libtool, and all associated files will
> | be deleted and no longer used.
> 
> This proposal seems to have been well-received.

This is probably a good thing.  The number one problem people have
installing SWIG bindings is runtime version mismatches.  This would
avoid that problem entirely.

-- 
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: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Max Bowsher wrote:
> Russell Yanofsky wrote:
>> I might be convinced if the SWIG project deleted their runtime
>> makefiles and MSVC project files and really did drop support for
>> automatically building the runtime libaries. Then the libraries
>> would cease to exist independently, and we'd be more justified in
>> absorbing them into our own libraries.
>
>
http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-November/012288.html
>
> says:
>
>> Proposal:
>> ---------
> ...
>> 7. The Runtime directory
>>
>> The current Runtime directory, libtool, and all associated files will
>> be deleted and no longer used.
>
> This proposal seems to have been well-received.

Interesting. Thanks for the link. To be sure though, some of the items in
this proposal look like they haven't been implemented, including #7. And
again, I'm not totally opposed to merging the libraries, I just wouldn't do
it that way myself.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Max Bowsher <ma...@ukf.net>.
Russell Yanofsky wrote:
> Max Bowsher wrote:
>> Russell Yanofsky wrote:
>>> Max Bowsher wrote:
>>>> Yes. I agree with all you say above. My point is that future
>>>> versions of swig will *NOT* install a swig runtime library.
>>>> Instead, swig users will be expected to run a swig command
>>>> generating a .c file which they compile and link into a library of
>>>> their own, which provides the swig runtime features.
>>> 
>>> Really? I know that they added a command to generate a .c file
>>> containing the runtime, but I didn't know they were going to get rid
>>> of the automatic build and install
>>> 
>>>> In our case, it seems to make the
>>>> most sense to integrate this into the existing libsvn_swig_py.
>>> 
>>> If we do have to start generating swig runtimes on unix (like we
>>> already do on windows), I think we should leave them as seperate
>>> libraries instead of combining them into the binding utility
>>> libraries. The two sets of libraries do different things and come
>>> from separate sources.
>> 
>> Depends how you think of it.
>> 
>> I think of them both doing the same thing: "being common support code
>> for the individual bindings libraries"
>> 
>> and coming from the same source: "the subversion build process".
>> 
>> Can you elaborate on why you don't like the idea of combining them?
>> Thanks.
> 
> Well I don't want to get too elaborate here ... this is another of one of
> those debates that basically boils down to personal preference, and I'm
> only -0 on the idea of combining the libraries.
> 
> There just seem to be some differences between the two sets of libraries.
> One set comes from the swig project, the other one comes from subversion.
> One set is specific to subversion and swig, the other one is only specific
> to swig. And the libraries mostly don't interact with each other. The
> subversion python utility library only calls two functions from the swig
> python runtime library.
> 
> I might be convinced if the SWIG project deleted their runtime makefiles and
> MSVC project files and really did drop support for automatically building
> the runtime libaries. Then the libraries would cease to exist independently,
> and we'd be more justified in absorbing them into our own libraries.

http://mailman.cs.uchicago.edu/pipermail/swig-dev/2003-November/012288.html

says:

| Proposal:
| ---------
...
| 7. The Runtime directory
| 
| The current Runtime directory, libtool, and all associated files will
| be deleted and no longer used.

This proposal seems to have been well-received.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Max Bowsher wrote:
> Russell Yanofsky wrote:
>> Max Bowsher wrote:
>>> Yes. I agree with all you say above. My point is that future
>>> versions of swig will *NOT* install a swig runtime library.
>>> Instead, swig users will be expected to run a swig command
>>> generating a .c file which they compile and link into a library of
>>> their own, which provides the swig runtime features.
>>
>> Really? I know that they added a command to generate a .c file
>> containing the runtime, but I didn't know they were going to get rid
>> of the automatic build and install
>>
>>> In our case, it seems to make the
>>> most sense to integrate this into the existing libsvn_swig_py.
>>
>> If we do have to start generating swig runtimes on unix (like we
>> already do on windows), I think we should leave them as seperate
>> libraries instead of combining them into the binding utility
>> libraries. The two sets of libraries do different things and come
>> from separate sources.
>
> Depends how you think of it.
>
> I think of them both doing the same thing: "being common support code
> for the individual bindings libraries"
>
> and coming from the same source: "the subversion build process".
>
> Can you elaborate on why you don't like the idea of combining them?
> Thanks.

Well I don't want to get too elaborate here ... this is another of one of
those debates that basically boils down to personal preference, and I'm
only -0 on the idea of combining the libraries.

There just seem to be some differences between the two sets of libraries.
One set comes from the swig project, the other one comes from subversion.
One set is specific to subversion and swig, the other one is only specific
to swig. And the libraries mostly don't interact with each other. The
subversion python utility library only calls two functions from the swig
python runtime library.

I might be convinced if the SWIG project deleted their runtime makefiles and
MSVC project files and really did drop support for automatically building
the runtime libaries. Then the libraries would cease to exist independently,
and we'd be more justified in absorbing them into our own libraries.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Max Bowsher <ma...@ukf.net>.
Russell Yanofsky wrote:
> Max Bowsher wrote:
>> Yes. I agree with all you say above. My point is that future versions
>> of swig will *NOT* install a swig runtime library. Instead, swig
>> users will be expected to run a swig command generating a .c file
>> which they compile and link into a library of their own, which
>> provides the swig runtime features.
> 
> Really? I know that they added a command to generate a .c file containing
> the runtime, but I didn't know they were going to get rid of the automatic
> build and install
> 
>> In our case, it seems to make the
>> most sense to integrate this into the existing libsvn_swig_py.
> 
> If we do have to start generating swig runtimes on unix (like we already do
> on windows), I think we should leave them as seperate libraries instead of
> combining them into the binding utility libraries. The two sets of libraries
> do different things and come from separate sources.

Depends how you think of it.

I think of them both doing the same thing: "being common support code for the individual bindings libraries"

and coming from the same source: "the subversion build process".

Can you elaborate on why you don't like the idea of combining them? Thanks.

Max.




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Max Bowsher wrote:
> Yes. I agree with all you say above. My point is that future versions
> of swig will *NOT* install a swig runtime library. Instead, swig
> users will be expected to run a swig command generating a .c file
> which they compile and link into a library of their own, which
> provides the swig runtime features.

Really? I know that they added a command to generate a .c file containing
the runtime, but I didn't know they were going to get rid of the automatic
build and install

> In our case, it seems to make the
> most sense to integrate this into the existing libsvn_swig_py.

If we do have to start generating swig runtimes on unix (like we already do
on windows), I think we should leave them as seperate libraries instead of
combining them into the binding utility libraries. The two sets of libraries
do different things and come from separate sources.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Branko ÄOibej wrote:
> Max Bowsher wrote:
>> Yes. I agree with all you say above. My point is that future
>> versions of swig will *NOT* install a swig runtime library. Instead,
>> swig users will be expected to run a swig command generating a .c
>> file which they compile and link into a library of their own, which
>> provides the swig runtime features. In our case, it seems to make
>> the most sense to integrate this into the existing libsvn_swig_py.
>>
>>
> Note that we already do this on Windows, even with SWIG-1.3.19. We can
> easily adapt the logic for Unix (it's infact quite portable).

Well, we do generate the swig runtime libraries on Windows but we don't
integrate them into the binding utility libraries.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Branko Čibej <br...@xbc.nu>.
Max Bowsher wrote:

>Russell Yanofsky wrote:
>  
>
>>Max Bowsher wrote:
>>    
>>
>>>I'm going to toss a very slightly related point into this
>>>discussion...
>>>
>>>SWIG is redefining how to use it's runtime library code.
>>>At some point in the future, we will no longer link libsvn_swig_py
>>>with -lswigpy, instead, we will run "swig -python -runtime
>>>swigrun.i", producing a C source file, which we will then compile and
>>>link into libsvn_swig_py itself.
>>>      
>>>
>>The "install-swig-py-lib" doesn't install the swig runtime -- we assume unix
>>users already have that installed. It installs our python utility library
>>(subversion/bindings/swig/python/libsvn_swig_py) which hold some common
>>functions used by all the python modules.
>>    
>>
>
>Yes. I agree with all you say above. My point is that future versions of swig will *NOT* install a swig runtime library. Instead,
>swig users will be expected to run a swig command generating a .c file which they compile and link into a library of their own,
>which provides the swig runtime features. In our case, it seems to make the most sense to integrate this into the existing
>libsvn_swig_py.
>  
>
Note that we already do this on Windows, even with SWIG-1.3.19. We can 
easily adapt the logic for Unix (it's infact quite portable).


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Max Bowsher <ma...@ukf.net>.
Russell Yanofsky wrote:
> Max Bowsher wrote:
>> I'm going to toss a very slightly related point into this
>> discussion...
>>
>> SWIG is redefining how to use it's runtime library code.
>> At some point in the future, we will no longer link libsvn_swig_py
>> with -lswigpy, instead, we will run "swig -python -runtime
>> swigrun.i", producing a C source file, which we will then compile and
>> link into libsvn_swig_py itself.
>
> The "install-swig-py-lib" doesn't install the swig runtime -- we assume unix
> users already have that installed. It installs our python utility library
> (subversion/bindings/swig/python/libsvn_swig_py) which hold some common
> functions used by all the python modules.

Yes. I agree with all you say above. My point is that future versions of swig will *NOT* install a swig runtime library. Instead,
swig users will be expected to run a swig command generating a .c file which they compile and link into a library of their own,
which provides the swig runtime features. In our case, it seems to make the most sense to integrate this into the existing
libsvn_swig_py.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Russell Yanofsky <re...@columbia.edu>.
Max Bowsher wrote:
> I'm going to toss a very slightly related point into this
> discussion...
>
> SWIG is redefining how to use it's runtime library code.
> At some point in the future, we will no longer link libsvn_swig_py
> with -lswigpy, instead, we will run "swig -python -runtime
> swigrun.i", producing a C source file, which we will then compile and
> link into libsvn_swig_py itself.

The "install-swig-py-lib" doesn't install the swig runtime -- we assume unix
users already have that installed. It installs our python utility library
(subversion/bindings/swig/python/libsvn_swig_py) which hold some common
functions used by all the python modules.

> ...
> In summary: To build and install the complete python bindings, "make
> swig-py install-swig-py" should be all that is required.

This seems right. I don't see why anybody would complain about that.

- Russ



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Wednesday, July 7, 2004 10:30 PM -0500 David Summers
> <da...@summersoft.fay.ar.us> wrote:
>
>> On #svn IRC channel, breser helped me figure it out.  The "make
>> install-swig-py-lib" is not being called (probably because it is not any
>> more dependent on the "make install-swig-py".
>
> install-swig-py-lib has never depended on install-swig-py.  Every time I
> brought that up before, someone complained that it should be separate.  So,
> this isn't recent.  It'd be nice to fix it though.  -- justin

I'm going to toss a very slightly related point into this discussion...

SWIG is redefining how to use it's runtime library code.
At some point in the future, we will no longer link libsvn_swig_py with -lswigpy, instead, we will run "swig -python -runtime
swigrun.i", producing a C source file, which we will then compile and link into libsvn_swig_py itself.

In other words, what I'm saying is that the distinction between the swig-py modules and the swig-py-lib will decrease, as they will
both use (at least some) swig-built source.

This means that in the future, "make swig-py" will really depend on "make swig-py-lib". I therefore think "swig-py-lib" should be
designated an internal developer convenience target (like, e.g. "make libsvn_subr"), and that "install-swig-py-lib" should be done
as part of "install-swig-py".

In summary: To build and install the complete python bindings, "make swig-py install-swig-py" should be all that is required.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: libsvn_swig_py.so not being installed

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Wednesday, July 7, 2004 10:30 PM -0500 David Summers 
<da...@summersoft.fay.ar.us> wrote:

> On #svn IRC channel, breser helped me figure it out.  The "make
> install-swig-py-lib" is not being called (probably because it is not any
> more dependent on the "make install-swig-py".

install-swig-py-lib has never depended on install-swig-py.  Every time I 
brought that up before, someone complained that it should be separate.  So, 
this isn't recent.  It'd be nice to fix it though.  -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org