You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Branko Čibej <br...@xbc.nu> on 2004/06/20 23:10:25 UTC
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig
subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
rey4@tigris.org wrote:
>Author: rey4
>Date: Sun Jun 20 16:18:36 2004
>New Revision: 10039
>
>Modified:
> trunk/build.conf
> trunk/build/generator/gen_base.py
> trunk/build/generator/gen_make.py
> trunk/build/generator/gen_win.py
> trunk/subversion/bindings/swig/INSTALL
> trunk/subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.c (contents, props changed)
> trunk/subversion/bindings/swig/perl/libsvn_swig_perl/swigutil_pl.h (contents, props changed)
> trunk/subversion/bindings/swig/perl/native/h2i.pl (contents, props changed)
>Log:
>Fix perl bindings on windows. These changes allow the swig modules
>to be built and loaded by perl. However, the bindings as a whole
>still don't work due to problems with the native modules
>(bindings/swig/perl/native/*.pm)
>
>
[...]
>Modified: trunk/build/generator/gen_base.py
>Url: http://svn.collab.net/viewcvs/svn/trunk/build/generator/gen_base.py?view=diff&rev=10039&p1=trunk/build/generator/gen_base.py&r1=10038&p2=trunk/build/generator/gen_base.py&r2=10039
>==============================================================================
>--- trunk/build/generator/gen_base.py (original)
>+++ trunk/build/generator/gen_base.py Sun Jun 20 16:18:36 2004
>@@ -529,7 +529,10 @@
>
> self.name = self.lang + libname
> self.path = os.path.join(self.path, self.lang)
>- self.filename = os.path.join(self.path, libfile)
>+ if self.lang == "perl":
>+ self.filename = os.path.join(self.path, libfile[0]+string.capitalize(libfile[1:]))
>+ else:
>+ self.filename = os.path.join(self.path, libfile)
>
>
I don't understand this. What's this for?
>Modified: trunk/build/generator/gen_make.py
>Url: http://svn.collab.net/viewcvs/svn/trunk/build/generator/gen_make.py?view=diff&rev=10039&p1=trunk/build/generator/gen_make.py&r1=10038&p2=trunk/build/generator/gen_make.py&r2=10039
>==============================================================================
>--- trunk/build/generator/gen_make.py (original)
>+++ trunk/build/generator/gen_make.py Sun Jun 20 16:18:36 2004
>@@ -138,6 +138,12 @@
>
> # for each install group, write a rule to install its outputs
> for itype, i_targets in install_deps:
>+
>+ # perl bindings do their own thing, "swig-pl" target is
>+ # already specified in Makefile.in
>+ if itype == "swig-pl":
>+ continue
>+
> outputs = [ ]
> for t in i_targets:
> if not isinstance(t, gen_base.TargetI18N) \
>@@ -160,6 +166,12 @@
> self.ofile.write('CLEAN_FILES = %s\n\n' % string.join(cfiles))
>
> for area, inst_targets in install_deps:
>+
>+ # perl bindings do their own thing, "install-swig-pl" target is
>+ # already specified in Makefile.in
>+ if area == "swig-pl":
>+ continue
>+
> # get the output files for these targets, sorted in dependency order
> files = gen_base._sorted_files(self.graph, area)
>
>
This is exactly the kind of exceptions we don't need. Is there really no
way to handle the perl SWIG bindings the same way as any other SWIG
bindings? At the very least, this should be handled with a _property_ of
the section in build.conf, the generator shouldn't depend on the section
name.
>+#ifdef _MSC_VER
>+#define snprintf _snprintf
>+#endif
>
>
Put this in defines instead. We do the same with alloca.
>+#ifdef _MSC_VER
>+#define strtoll(str, endptr, base) atoi(str)
>+#endif
>
>
That's asking for trouble. Use _strtoi64 with MSVC 7 and above (#if
_MSC_VER >= 1300 && _INTEGRAL_MAX_BITS >= 64). Use _atoi64 otherwise.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 28, 2004 at 02:19:14PM -0400, Russell Yanofsky wrote:
> Whether they change or not is irrelevant. I'm only saying that because
> they are public interfaces used by lots of external projects, they
> shouldn't require all code that interacts with them to be built with
> weird compiler options.
In an ideal world you'd be right! But ... :)
> I'm not saying we should filter the options in ccopts, I'm saying we should
> ignore them entirely.
I realize that...
> They don't /unfortunately/ clash with standard names, they
> /intentionally/ clash with standard names to implement functionality
> that has nothing to do with the subversion bindings.
Well what I think they should do is use macros for these functions, then
point them to their own implementation or to a C lib implementation,
depending upon what they want. Perl is setup to allow embeding, so even
in the ideal world mentioned above, this would still be nice for those
embedding a Perl interpretor into their app.
But this is the wrong list for that discussion.
> > > Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
> > > invasive. I can't imagine that perl would require extensions to be built
> > > with them.
> >
> > They come form $Config{ccflags} which MakeMaker uses.
>
> Isn't it our makefile.pl script that is putting perl ccopts there?
If we weren't overriding CCFLAGS with other stuff it'd be there
automatically. But since we're overriding stuff in CCFLAGS we had to
ask for it on our own.
Incidentally, I tried removing ccopts() from the build and this is what
I get when I do that:
In file included from
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/op.h:484,
from
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/perl.h:2346,
from core.c:292:
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/reentr.h:611: error:
field `_crypt_struct' has incomplete type
In file included from
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/perl.h:3554,
from core.c:292:
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:199: error:
parse error before "off64_t"
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:201: error:
parse error before "Perl_do_sysseek"
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:201: error:
parse error before "off64_t"
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:201:
warning: data definition has no type or storage class
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:202: error:
parse error before "Perl_do_tell"
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:202:
warning: data definition has no type or storage class
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:1307: error:
parse error before "Perl_PerlIO_tell"
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:1307:
warning: data definition has no type or storage class
/usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/CORE/proto.h:1308: error:
parse error before "off64_t"
make[1]: *** [core.o] Error 1
make[1]: Leaving directory
`/home/breser/wc/svn-trunk/subversion/bindings/swig/perl/native'
make: *** [swig-pl] Error 2
Upon further review I realized that we really shouldn't be using
CCFLAGS, but should be using INC since everything that goes into that
really is a include path.
So as of 10097 we no longer call ccopts() and are using INC. But you'll
note that flags you dislike are still in the build. Because MakeMaker
is now providing them, just like it would have been doing if we'd been
doing what we should have been doing before.
> Well, you know what the options are for getting makefile.pl to work on windows.
> You can go about it however you like. I just think it would be better to
> manually specify compiler options appropriate for the subversion bindings
> instead of copying the options used to build perl.
That's just the way Perl extensions are built. Failing to follow that
is bound to cause problems for people, as you can see above.
Incidentally, you can now easily override the CCFLAGS that perl provides
by doing:
perl Makefile.PL CCFLAGS=somethingelse
Without having to specify all the other includes that we had in there.
So the correctness issue should make life easier for you to bypass the
build flags that you think are wrong.
> Agreed. This issue (#1627) was solved back in January, but it was put
> on hold (I think) because of the subversion 1.0 release.
Well the perl bindings don't even work for me with a static build on
*nix. I've been trying to figure it out. It complains about missing
symbols that are in libraries that are being passed to the linker.
When I fix that for *nix it might help some for Windows and the linking.
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
"Ben Reser" <be...@reser.org> wrote in message
news:20040628062134.GC3450@synapse.brain.org...
> On Sun, Jun 27, 2004 at 11:16:16PM -0400, Russell Yanofsky wrote:
> > We're not using perl internals, we're just using a handful of public, well
> > documented API's that perl provides for extension writers. The API's don't
> > require us to use weird compiler flags, so we shouldn't use them.
>
> They're still internals. There are no guarantees that the interfaces
> stay the same, and often do change.
Whether they change or not is irrelevant. I'm only saying that because they are
public interfaces used by lots of external projects, they shouldn't require all
code that interacts with them to be built with weird compiler options.
> They're documented in a man page
> called "perlguts".
Them perl people be so clever.
> > > Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
> > > 64-bits long. But the default is to use 32-bit off_t's. So when we
> > > give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
> > > we'll get a segfault...
> >
> > I don't think we should be using -D_FILE_OFFSET_BITS either, see
> > http://www.contactor.se/~dast/svn/archive-2004-01/0471.shtml
>
> We're not choosing to use it. The person who built Perl is. Right or
> wrong it's there. We could filter it out. But I don't think that's
> right.
I'm not saying we should filter the options in ccopts, I'm saying we should
ignore them entirely.
> Right now we don't happen to be using any function calls that
> not having it is going to impact. But if we ever do start using
> PerlIO_tell, PerlIO_seek, etc... we will be impacted by not pulling it
> in. IMHO it is the entirely wrong to have a build system that'll break
> just because we decided to seek...
If adding a call to seek breaks something, then it's not the build system's
fault, it's perl's fault for redefining standard types and then using those
messed up types in its public interface. The correct solution to that problem,
should it ever occur, would be to isolate calls to the perl IO calls in a single
source file, build that one source file with perl ccopts, and write a long
comment at the top of the source file saying nasty things about perl developers.
IMHO, it is entirely wrong that builds of the subversion bindings will only work
under certain configurations of perl. There is no reasons for the bindings to
break just because perl was built with IMPLICIT_SYS or OFFSET_BITS=64 or some
other option that is totally unrelated to their functioning.
> > Maybe it is neccessary for Perl to emulate fork under windows, but we're not
> > building Perl. We're building the subversion bindings, which do not work
> > with PERL_IMPLICIT_SYS. PERL_IMPLICIT_SYS causes the perl headers to #define
> > bunch of posix and standard C functions, which interferes with the Microsoft
> > headers included by APR.
>
> This isn't anything unique to Windows. Perl defines lots of function
> names that unfortunately clash with standard names. Refer to the past
> dicussion about warnings from the build of the perl bindings.
They don't /unfortunately/ clash with standard names, they /intentionally/ clash
with standard names to implement functionality that has nothing to do with the
subversion bindings.
> > Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
> > invasive. I can't imagine that perl would require extensions to be built
> > with them.
>
> They come form $Config{ccflags} which MakeMaker uses.
Isn't it our makefile.pl script that is putting perl ccopts there?
> So as much as you
> can't imagine it, they are the proper flags for building extensions to
> Perl.
I'll admit that the perl way of doing things is pretty foreign to me.
> We can simply ignore them on Windows. But I seriously think this is the
> wrong thing to do.
Well, you know what the options are for getting makefile.pl to work on windows.
You can go about it however you like. I just think it would be better to
manually specify compiler options appropriate for the subversion bindings
instead of copying the options used to build perl.
> > On windows, the subversion libraries are currently static so you need to
> > link against the libraries they depend on.
>
> I thought they were going to be DLLs? It seems really silly to be doing
> statics. We end up with the libs built into the command line client,
> the svnadmin command, the python bindings, the perl bindings, and the
> java bindings. What a horrible overkill.
Agreed. This issue (#1627) was solved back in January, but it was put on hold (I
think) because of the subversion 1.0 release.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Sun, Jun 27, 2004 at 11:16:16PM -0400, Russell Yanofsky wrote:
> We're not using perl internals, we're just using a handful of public, well
> documented API's that perl provides for extension writers. The API's don't
> require us to use weird compiler flags, so we shouldn't use them.
They're still internals. There are no guarantees that the interfaces
stay the same, and often do change. They're documented in a man page
called "perlguts".
> > Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
> > 64-bits long. But the default is to use 32-bit off_t's. So when we
> > give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
> > we'll get a segfault...
>
> I don't think we should be using -D_FILE_OFFSET_BITS either, see
> http://www.contactor.se/~dast/svn/archive-2004-01/0471.shtml
We're not choosing to use it. The person who built Perl is. Right or
wrong it's there. We could filter it out. But I don't think that's
right. Right now we don't happen to be using any function calls that
not having it is going to impact. But if we ever do start using
PerlIO_tell, PerlIO_seek, etc... we will be impacted by not pulling it
in. IMHO it is the entirely wrong to have a build system that'll break
just because we decided to seek...
> Maybe it is neccessary for Perl to emulate fork under windows, but we're not
> building Perl. We're building the subversion bindings, which do not work
> with PERL_IMPLICIT_SYS. PERL_IMPLICIT_SYS causes the perl headers to #define
> bunch of posix and standard C functions, which interferes with the Microsoft
> headers included by APR.
This isn't anything unique to Windows. Perl defines lots of function
names that unfortunately clash with standard names. Refer to the past
dicussion about warnings from the build of the perl bindings.
> Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
> invasive. I can't imagine that perl would require extensions to be built
> with them.
They come form $Config{ccflags} which MakeMaker uses. So as much as you
can't imagine it, they are the proper flags for building extensions to
Perl.
We can simply ignore them on Windows. But I seriously think this is the
wrong thing to do.
> On windows, the subversion libraries are currently static so you need to
> link against the libraries they depend on.
I thought they were going to be DLLs? It seems really silly to be doing
statics. We end up with the libs built into the command line client,
the svnadmin command, the python bindings, the perl bindings, and the
java bindings. What a horrible overkill.
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> On Sun, Jun 27, 2004 at 06:41:49PM -0400, Russell Yanofsky wrote:
>> I don't understand why the bindings have to be built with the same
>> compiler flags as perl itself. Some of them, like
>> -DPERL_IMPLICIT_SYS, are clearly inappropriate.
>
> Because we use Perl internals. There are a variety of things that
> change those internals slightly. Many things in these internals are
> done with macros. So if you don't have all the flags set then our
> calls to Perl will be out of sync with what the actual perl binary
> expects.
We're not using perl internals, we're just using a handful of public, well
documented API's that perl provides for extension writers. The API's don't
require us to use weird compiler flags, so we shouldn't use them.
> Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
> 64-bits long. But the default is to use 32-bit off_t's. So when we
> give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
> we'll get a segfault...
I don't think we should be using -D_FILE_OFFSET_BITS either, see
http://www.contactor.se/~dast/svn/archive-2004-01/0471.shtml
>
> I really don't understand why you think -DPERL_IMPLICIT_SYS is
> inappropriate? From what I understand PERL_IMPLICIT_SYS is necessary
> for Perl to emulate fork() under Windows.
Maybe it is neccessary for Perl to emulate fork under windows, but we're not
building Perl. We're building the subversion bindings, which do not work
with PERL_IMPLICIT_SYS. PERL_IMPLICIT_SYS causes the perl headers to #define
bunch of posix and standard C functions, which interferes with the Microsoft
headers included by APR.
> Just because removing it makes the build work doesn't mean that it's
> not necessary. You might even be lucky that your platform happens to
> be mostly default and not subject to any definitions...
Options like -DPERL_IMPLICIT_SYS and -D_FILE_OFFSET_BITS=64 are pretty
invasive. I can't imagine that perl would require extensions to be built
with them.
>> No. Many of the .lib files are import libraries which are used on
>> windows to link to DLLs. Some of them are plain old static libaries
>> though.
>
> Shouldn't the only libs you need to pull in then are the subversion
> libs? They should already be linked against the import libraries for
> the DLLs they need or for the static libs for anything else? The only
> thing we use directly at all (besides the Subversion libraries) would
> be APR. And that's for the pool code and the apr_initialize() and
> apr_terminate(). Not sure if pulling in the Subversion libs is enough
> for the MSVC linker to give us the apr functions or not...
On windows, the subversion libraries are currently static so you need to
link against the libraries they depend on.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Sun, Jun 27, 2004 at 06:41:49PM -0400, Russell Yanofsky wrote:
> How do I fix it if I'm using the binary version of ActiveState Perl? I don't
> understand why the bindings have to be built with the same compiler flags as
> perl itself. Some of them, like -DPERL_IMPLICIT_SYS, are clearly
> inappropriate.
Because we use Perl internals. There are a variety of things that
change those internals slightly. Many things in these internals are
done with macros. So if you don't have all the flags set then our calls
to Perl will be out of sync with what the actual perl binary expects.
Say Perl was built with -D_FILE_OFFSET_BITS=64, then off_t will be
64-bits long. But the default is to use 32-bit off_t's. So when we
give Perl an off_t that is 32-bits and it is expecting a 64-bit off_t
we'll get a segfault...
I really don't understand why you think -DPERL_IMPLICIT_SYS is
inappropriate? From what I understand PERL_IMPLICIT_SYS is necessary
for Perl to emulate fork() under Windows.
Just because removing it makes the build work doesn't mean that it's not
necessary. You might even be lucky that your platform happens to be
mostly default and not subject to any definitions...
> The MS linker probably does support -L -l and standard search paths. I
> didn't use them because I dodn't know how they work offhand.
I'll commit something that I think will work for the Subversion
libraries then.
> No. Many of the .lib files are import libraries which are used on windows to
> link to DLLs. Some of them are plain old static libaries though.
Shouldn't the only libs you need to pull in then are the subversion
libs? They should already be linked against the import libraries for
the DLLs they need or for the static libs for anything else? The only
thing we use directly at all (besides the Subversion libraries) would be
APR. And that's for the pool code and the apr_initialize() and
apr_terminate(). Not sure if pulling in the Subversion libs is enough
for the MSVC linker to give us the apr functions or not...
> > I guess I don't see a good way of detecting at build time all of that.
>
> You can get the locations of the external libraries by reading the
> gen-make.opts file which is written by the build generator. Here's what one
> from my system looks like:
>
> -- snip --
> [options]
> --with-berkeley-db = ..\db4-win32
> --with-apr = ..\httpd-2.0.49\srclib\apr
> --with-apr-util = ..\httpd-2.0.49\srclib\apr-util
> --with-apr-iconv = ..\httpd-2.0.49\srclib\apr-iconv
> --with-httpd = ..\httpd-2.0.49
> --with-openssl = ..\openssl-0.9.7d
> --with-zlib = ..\zlib113-win32
> -- snip --
If the only thing we need besides the relative paths to the .libs, is
APR, then we should pull in the equivalent of SVN_APR_LIBS...
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> The Config values are probably set for the build environment used to
> build the version of Perl you have installed. If you didn't build it
> yourself and it was built with a different toolchain, it very likely
> won't be right. This means you need to fix it.
How do I fix it if I'm using the binary version of ActiveState Perl? I don't
understand why the bindings have to be built with the same compiler flags as
perl itself. Some of them, like -DPERL_IMPLICIT_SYS, are clearly
inappropriate.
> Yikes, some of these are outside our source tree. Also doens't the
> MS linker use -L and -l? Shouldn't some of these e.g. K:/Program
> Files/Microsoft SDK/Lib/SHFolder.Lib be on the standard search path?
The MS linker probably does support -L -l and standard search paths. I
didn't use them because I dodn't know how they work offhand.
> From the looks of it, it seems to me that you're statically linking
> everything in. Is this the case?
No. Many of the .lib files are import libraries which are used on windows to
link to DLLs. Some of them are plain old static libaries though.
> I guess I don't see a good way of detecting at build time all of that.
You can get the locations of the external libraries by reading the
gen-make.opts file which is written by the build generator. Here's what one
from my system looks like:
-- snip --
[options]
--with-berkeley-db = ..\db4-win32
--with-apr = ..\httpd-2.0.49\srclib\apr
--with-apr-util = ..\httpd-2.0.49\srclib\apr-util
--with-apr-iconv = ..\httpd-2.0.49\srclib\apr-iconv
--with-httpd = ..\httpd-2.0.49
--with-openssl = ..\openssl-0.9.7d
--with-zlib = ..\zlib113-win32
-- snip --
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Sat, Jun 26, 2004 at 01:44:36PM -0400, Russell Yanofsky wrote:
> * Stop picking up compiler options from `perl -MExtUtils::Embed -e ccopts`
> On ActiveState Perl this returns options like -DPERL_IMPLICIT_SYS which
> don't work with the subversion bindings on Windows.
This means your perl is misconfigured. ccopts just prints runs:
perl_inc(), ccflags() and ccdlflags()
perl_inc() prints:
-I$Config{archlibexp}/CORE
ccflags prints:
$Config{cclfags}
and
ccdlflags prints:
$Config{ccdlflags}
The Config values are probably set for the build environment used to
build the version of Perl you have installed. If you didn't build it
yourself and it was built with a different toolchain, it very likely
won't be right. This means you need to fix it.
> * Specify different library paths because libraries have different names and
> locations on windows
See below...
> * Invoke 'nmake' instead of 'make' internally
Yup we should be using $(MAKE) not make in the Makefile.
> - LIBS => [join(' ', $apr_ldflags,
> - (map {$_ = abs_path($_); "-L$_"} @ldpaths),
> - @ldmodules, '-lsvn_swig_perl-1',
> - `$swig -perl -ldflags`)],
> + LIBS => [join(' ', ('M:/russ/source/svn/Release/subversion/bindings/swig/perl/swigpl.lib',
> + 'M:/russ/source/svn/Release/subversion/bindings/swig/perl/libsvn_swig_perl/libsvn_swig_perl-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_client/libsvn_client-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_delta/libsvn_delta-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_diff/libsvn_diff-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_fs/libsvn_fs-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_fs_base/libsvn_fs_base-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_fs_fs/libsvn_fs_fs-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_ra/libsvn_ra-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_ra_dav/libsvn_ra_dav-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_ra_local/libsvn_ra_local-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_ra_svn/libsvn_ra_svn-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_repos/libsvn_repos-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_subr/libsvn_subr-1.lib',
> + 'M:/russ/source/svn/Release/subversion/libsvn_wc/libsvn_wc-1.lib',
> + 'M:/russ/source/httpd-2.0.49/srclib/apr/Release/libapr.lib',
> + 'M:/russ/source/httpd-2.0.49/srclib/apr-iconv/Release/libapriconv.lib',
> + 'M:/russ/source/httpd-2.0.49/srclib/apr-util/Release/libaprutil.lib',
> + 'M:/russ/source/httpd-2.0.49/srclib/apr-util/xml/expat/lib/LibR/xml.lib',
> + '"K:/Program Files/Microsoft SDK/Lib/ShFolder.Lib"',
> + 'M:/russ/source/svn/neon/libneon.lib',
> + 'M:/russ/source/db4-win32/lib/libdb42.lib'))],
Yikes, some of these are outside our source tree. Also doens't the MS
linker use -L and -l? Shouldn't some of these e.g. K:/Program
Files/Microsoft SDK/Lib/SHFolder.Lib be on the standard search path?
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> That's why it's generated by autoconf, so it doesn't directly depend
> upon the apr config programs. On Windows you can have the build
> generator replace the @FOO@ symbols into the proper values.
>
> To see if the build works, you can just do this by hand for now.
Replacing the symbols and making a few other changes got the build working.
Here's a list of the changes I had to make and a patch showing them for my
system:
* Set values for autoconf variables: @top_srcdir@, @top_builddir@,
@SWIG_VERSION@, @SWIG@, @SVN_APR_INCLUDES@, @SVN_APRUTIL_INCLUDES@, and
@SVN_APR_EXPORT_LIBS@
* Stop picking up compiler options from `perl -MExtUtils::Embed -e ccopts`
On ActiveState Perl this returns options like -DPERL_IMPLICIT_SYS which
don't work with the subversion bindings on Windows.
* Specify different library paths because libraries have different names and
locations on windows
* Invoke 'nmake' instead of 'make' internally
- Russ
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> On Mon, Jun 21, 2004 at 03:17:31PM -0400, Russell Yanofsky wrote:
>> ...
>> Cannot chdir to ../libsvn_swig_perl/.libs: No such file or directory
>> at Makefile.PL line 45
>>
>> It needs to be rewritten to not depend on the apr config programs
>> which don't exist on windows.
>
> That's why it's generated by autoconf, so it doesn't directly depend
> upon the apr config programs. On Windows you can have the build
> generator replace the @FOO@ symbols into the proper values.
>
> To see if the build works, you can just do this by hand for now.
I filled in the values by hand and got a shorter version of the same error.
Cannot chdir to
M:/russ/source/svn/subversion/bindings/swig/perl/libsvn_swig_perl/.libs: No
such file or directory at Makefile.pl line 34
The error comes from calls to abs_path with a bunch of .libs paths which
don't exist on windows (because we don't use libtool there). Commenting out
the following lines took care of the problem well enough for the script to
be able to generate Makefiles:
LIBS => [join(' ', $apr_ldflags,
(map {$_ = abs_path($_); "-L$_"} @ldpaths),
@ldmodules, '-lsvn_swig_perl-1',
`$swig -perl -ldflags`)],
But ATM, running nmake on those generated Makefiles just gives another
error:
NMAKE : fatal error U1073: don't know how to make 'K:\Program'
because MakeMaker apparently doesn't handle paths with spaces. I'm going to
try installing perl in a path without a space to see if what will happen
then.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 21, 2004 at 03:17:31PM -0400, Russell Yanofsky wrote:
> Makefile.PL doesn't exist any more on windows because it's now generated by
> autoconf. But when I try the old Makefile.PL file (taken from rev 9270), I
> get
>
> M:\russ\source\svn\subversion\bindings\swig\perl\native>perl Makefile.PL
> 'apr-config' is not recognized as an internal or external command,
> operable program or batch file.
> 'apr-config' is not recognized as an internal or external command,
> operable program or batch file.
> 'apu-config' is not recognized as an internal or external command,
> operable program or batch file.
> 'K:\Program' is not recognized as an internal or external command,
> operable program or batch file.
> Cannot chdir to ../libsvn_swig_perl/.libs: No such file or directory at
> Makefile.PL line 45
>
> It needs to be rewritten to not depend on the apr config programs which
> don't exist on windows.
That's why it's generated by autoconf, so it doesn't directly depend
upon the apr config programs. On Windows you can have the build
generator replace the @FOO@ symbols into the proper values.
To see if the build works, you can just do this by hand for now.
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> If someone can try doing:
>
> perl Makefile.PL
> nmake
> nmake test
>
> from subversion/bindings/swig/perl/native
>
> that would tell me a whole lot...
Makefile.PL doesn't exist any more on windows because it's now generated by
autoconf. But when I try the old Makefile.PL file (taken from rev 9270), I
get
M:\russ\source\svn\subversion\bindings\swig\perl\native>perl Makefile.PL
'apr-config' is not recognized as an internal or external command,
operable program or batch file.
'apr-config' is not recognized as an internal or external command,
operable program or batch file.
'apu-config' is not recognized as an internal or external command,
operable program or batch file.
'K:\Program' is not recognized as an internal or external command,
operable program or batch file.
Cannot chdir to ../libsvn_swig_perl/.libs: No such file or directory at
Makefile.PL line 45
It needs to be rewritten to not depend on the apr config programs which
don't exist on windows.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Patrick Mayweg wrote:
> Hi Ben,
> Ben Reser wrote:
>> ...
>> If someone can try doing:
>>
>> perl Makefile.PL
>> nmake
>> nmake test
>>
>>
> "Custom Build Steps" should be your friend. I have added support for
> compiling java class for the javahl binding in that way. Brane and I
> have a discussion going on, how these can be extended for other needes
> during the subversion build.
>
Custom build steps are what I used to get the perl bindings to build. But
he's talking about another approach that avoids visual studio and the build
generator entirely and just uses the microsoft command line tools and perl.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by "Michael S. Liebman" <m-...@northwestern.edu>.
On Mon, Jun 21, 2004 at 06:14:20AM -0700, Ben Reser wrote:
> On Mon, Jun 21, 2004 at 03:00:03PM +0200, Patrick Mayweg wrote:
> But until I can at least see the output of someone trying, I have no
> idea what the tweaks might be.
I am more than happy to try this out. However, I may need some help
turning Makefile.PL.in into a valid Makefile.PL.
Michael
--
Michael S. Liebman m-liebman@northwestern.edu
http://msl521.freeshell.org/
"I have vision and the rest of the world wears bifocals."
-Paul Newman in "Butch Cassidy & the Sundance Kid"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 21, 2004 at 03:00:03PM +0200, Patrick Mayweg wrote:
> "Custom Build Steps" should be your friend. I have added support for
> compiling java class for the javahl binding in that way. Brane and I
> have a discussion going on, how these can be extended for other needes
> during the subversion build.
I have no idea how this helps. I don't even know what you are referring
to by "Custom Build Steps." Even if we can get the Windows build setup
to run the Perl build infrastructure, I still need someone to test it
and tell me if it works on Windows. I'm not sure it does, but then I'm
not sure it doesn't. Might take some tweaks. I know we're generating
some of our own targets because perl doesn't know how to ask swig to
generate the source files...
But until I can at least see the output of someone trying, I have no
idea what the tweaks might be.
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig
subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Patrick Mayweg <ma...@qint.de>.
Hi Ben,
Ben Reser wrote:
>On Mon, Jun 21, 2004 at 11:38:37AM +0200, Branko ??ibej wrote:
>
>
>>So right now we have the worst possible situation, with Unix and Windows
>>doing completely different things with the Perl bindings. Hm.
>>
>>I see Unix uses the Perl infrastructure (Makfile.PL, and such) for
>>building and installing the bindings. I suggest Windows should do the
>>same, because Perl _does_ support building on Windws using the same
>>mechanism.
>>
>>Can we work on making it so?
>>
>>
>
>I've been begging people to help me do so for ages. People say they'll
>do it and never do, complain about the need for a make command (turns
>out later that MSVC comes with nmake, which Perl can and will generate
>Makefile's for), ...
>
>If someone can try doing:
>
>perl Makefile.PL
>nmake
>nmake test
>
>
"Custom Build Steps" should be your friend. I have added support for
compiling java class for the javahl binding in that way. Brane and I
have a discussion going on, how these can be extended for other needes
during the subversion build.
>from subversion/bindings/swig/perl/native
>
>that would tell me a whole lot...
>
>
>
Patrick
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 21, 2004 at 11:38:37AM +0200, Branko ??ibej wrote:
> So right now we have the worst possible situation, with Unix and Windows
> doing completely different things with the Perl bindings. Hm.
>
> I see Unix uses the Perl infrastructure (Makfile.PL, and such) for
> building and installing the bindings. I suggest Windows should do the
> same, because Perl _does_ support building on Windws using the same
> mechanism.
>
> Can we work on making it so?
I've been begging people to help me do so for ages. People say they'll
do it and never do, complain about the need for a make command (turns
out later that MSVC comes with nmake, which Perl can and will generate
Makefile's for), ...
If someone can try doing:
perl Makefile.PL
nmake
nmake test
from subversion/bindings/swig/perl/native
that would tell me a whole lot...
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig
subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>There's no reason we can't make the Makefile.PL work for Windows. Like
>I pointed out before the symbols that need to be filled in to make a
>Makefile.PL from Makefile.PL.in, you probably already have. I'm more
>than willing to work with you to get Makefile.PL to work on Windows.
>
>
+1 on that, and if you need any help, I can scrounge some time
somewhere. I'll be happy if the Perl bindings are handled consistently
on Windows and Unix, even if they're handled differently from the other
SWIG bindings.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> On Mon, Jun 21, 2004 at 02:58:32PM -0400, Russell Yanofsky wrote:
>> Ben Reser wrote:
>>> We're using the infrastructure that Perl
>>> provides for building and installing extensions. In order to just
>>> use the generator we'd have to re-engineer all of this
>>> infrastructure. I'm not inclined to do that...
>>
>> Couldn't you use the build generator to build the extensions and the
>> existing Perl infrastructure to install them? The build generator
>> already knows how to build swig modules, it just needs to be tweaked
>> to use the right parameters and filenames.
>
> The build generator only knows how to build the libsvn_swig_perl
> library. As far as I know it has never known how to build the actual
> bindings, not just our support library, properly.
>
> I find it really odd that you advocated a build process that is
> obviously completely different than the other swig bindings builds and
> then 4 minutes later argue against the current setup on the basis that
> it is different the other swig bindings build.
Huh? I've advocated using the subversion make generator instead of MakeMaker
to build the perl modules. This is closer to what the other languages do.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 21, 2004 at 03:02:10PM -0400, Russell Yanofsky wrote:
> Branko ÄOibej wrote:
> > So right now we have the worst possible situation, with Unix and
> > Windows doing completely different things with the Perl bindings. Hm.
> >
> > I see Unix uses the Perl infrastructure (Makfile.PL, and such) for
> > building and installing the bindings. I suggest Windows should do the
> > same, because Perl _does_ support building on Windws using the same
> > mechanism.
> >
> > Can we work on making it so?
>
> That's a reasonable solution, although I don't like it because it would mean
> you could no longer build the bindings with Visual Studio and because it
> would make the perl bindings build differently than the other swig bindings.
I don't see why this is a problem. They're already built differently
than the other swig bindings on unix like operating systems. But not
only that we're talking about language bindings. The idea that they all
should be built exactly the same way in some cookie cutter way seems to
me to be flawed. The target languages are necessarily different.
On Mon, Jun 21, 2004 at 02:58:32PM -0400, Russell Yanofsky wrote:
> Ben Reser wrote:
> > The perl bindings are not in build.conf anymore, with the exception of
> > the swig-pl-lib target.
>
> The perl bindings are back in build.conf, I had to add them so they could
> build under windows.
Yeah and I'm not thrilled about this. We now have targets sitting in
the build-outputs.mk that are total useless and don't work anyway.
$ make subversion/bindings/swig/perl/_Client.la
mkdir subversion/bindings/swig/java/build
/home/breser/wc/svn-trunk/subversion/bindings/swig/svn_client.i
make: execvp:
/home/breser/wc/svn-trunk/subversion/bindings/swig/svn_client.i:
Permission denied
make: *** [subversion/bindings/swig/perl/svn_client.c] Error 127
(And why the heck is it making a java directory to build a perl target)?
> > We're using the infrastructure that Perl
> > provides for building and installing extensions. In order to just use
> > the generator we'd have to re-engineer all of this infrastructure.
> > I'm not inclined to do that...
>
> Couldn't you use the build generator to build the extensions and the
> existing Perl infrastructure to install them? The build generator already
> knows how to build swig modules, it just needs to be tweaked to use the
> right parameters and filenames.
The build generator only knows how to build the libsvn_swig_perl
library. As far as I know it has never known how to build the actual
bindings, not just our support library, properly.
I find it really odd that you advocated a build process that is
obviously completely different than the other swig bindings builds and
then 4 minutes later argue against the current setup on the basis that
it is different the other swig bindings build.
There's no reason we can't make the Makefile.PL work for Windows. Like
I pointed out before the symbols that need to be filled in to make a
Makefile.PL from Makefile.PL.in, you probably already have. I'm more
than willing to work with you to get Makefile.PL to work on Windows.
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko ÄOibej wrote:
> So right now we have the worst possible situation, with Unix and
> Windows doing completely different things with the Perl bindings. Hm.
>
> I see Unix uses the Perl infrastructure (Makfile.PL, and such) for
> building and installing the bindings. I suggest Windows should do the
> same, because Perl _does_ support building on Windws using the same
> mechanism.
>
> Can we work on making it so?
That's a reasonable solution, although I don't like it because it would mean
you could no longer build the bindings with Visual Studio and because it
would make the perl bindings build differently than the other swig bindings.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig
subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Branko Čibej <br...@xbc.nu>.
Ben Reser wrote:
>On Mon, Jun 21, 2004 at 01:10:25AM +0200, Branko ??ibej wrote:
>
>
>>This is exactly the kind of exceptions we don't need. Is there really no
>>way to handle the perl SWIG bindings the same way as any other SWIG
>>bindings? At the very least, this should be handled with a _property_ of
>>the section in build.conf, the generator shouldn't depend on the section
>>name.
>>
>>
>
>The perl bindings are not in build.conf anymore, with the exception of
>the swig-pl-lib target. We're using the infrastructure that Perl
>provides for building and installing extensions. In order to just use
>the generator we'd have to re-engineer all of this infrastructure. I'm
>not inclined to do that...
>
So right now we have the worst possible situation, with Unix and Windows
doing completely different things with the Perl bindings. Hm.
I see Unix uses the Perl infrastructure (Makfile.PL, and such) for
building and installing the bindings. I suggest Windows should do the
same, because Perl _does_ support building on Windws using the same
mechanism.
Can we work on making it so?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Ben Reser wrote:
> The perl bindings are not in build.conf anymore, with the exception of
> the swig-pl-lib target.
The perl bindings are back in build.conf, I had to add them so they could
build under windows.
> We're using the infrastructure that Perl
> provides for building and installing extensions. In order to just use
> the generator we'd have to re-engineer all of this infrastructure.
> I'm not inclined to do that...
Couldn't you use the build generator to build the extensions and the
existing Perl infrastructure to install them? The build generator already
knows how to build swig modules, it just needs to be tweaked to use the
right parameters and filenames.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Ben Reser <be...@reser.org>.
On Mon, Jun 21, 2004 at 01:10:25AM +0200, Branko ??ibej wrote:
> This is exactly the kind of exceptions we don't need. Is there really no
> way to handle the perl SWIG bindings the same way as any other SWIG
> bindings? At the very least, this should be handled with a _property_ of
> the section in build.conf, the generator shouldn't depend on the section
> name.
The perl bindings are not in build.conf anymore, with the exception of
the swig-pl-lib target. We're using the infrastructure that Perl
provides for building and installing extensions. In order to just use
the generator we'd have to re-engineer all of this infrastructure. I'm
not inclined to do that...
--
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: svn commit: r10039 - in trunk: . build/generator subversion/bindings/swig subversion/bindings/swig/perl/libsvn_swig_perl subversion/bindings/swig/perl/native
Posted by Russell Yanofsky <re...@columbia.edu>.
Branko ÄOibej wrote:
>>
>> self.name = self.lang + libname
>> self.path = os.path.join(self.path, self.lang)
>> - self.filename = os.path.join(self.path, libfile)
>> + if self.lang == "perl":
>> + self.filename = os.path.join(self.path,
>> libfile[0]+string.capitalize(libfile[1:])) + else:
>> + self.filename = os.path.join(self.path, libfile)
>>
>>
> I don't understand this. What's this for?
Just to give perl modules names like _Client.dll and _Core.dll instead of
_client.dll and _core.dll. It's probably not neccessary on Windows, but I
was just being cautious.
>> + # perl bindings do their own thing, "install-swig-pl" target
>> is + # already specified in Makefile.in
>> + if area == "swig-pl":
>> + continue
>> +
>> # get the output files for these targets, sorted in dependency
>> order files = gen_base._sorted_files(self.graph, area)
>>
>>
> This is exactly the kind of exceptions we don't need. Is there really
> no way to handle the perl SWIG bindings the same way as any other SWIG
> bindings? At the very least, this should be handled with a _property_
> of the section in build.conf, the generator shouldn't depend on the
> section name.
Technically, it depends on the install name, not the section name. And the
generator code already makes similar exceptions. I agree that it would be
nice if the perl bindngs built the same way as other SWIG bindings on unix,
but they don't, and I don't know enough about perl or the unix build system
to make them do that. I can change the code above though.
>
>> +#ifdef _MSC_VER
>> +#define snprintf _snprintf
>> +#endif
>>
>>
> Put this in defines instead. We do the same with alloca.
>
>> +#ifdef _MSC_VER
>> +#define strtoll(str, endptr, base) atoi(str)
>> +#endif
>>
>>
> That's asking for trouble. Use _strtoi64 with MSVC 7 and above (#if
> _MSC_VER >= 1300 && _INTEGRAL_MAX_BITS >= 64). Use _atoi64 otherwise.
>
Ok, thanks for the information. I'll clean these up.
- Russ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org