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