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?
> 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.
| 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Jul 8 19:05:29 2004