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 <ben@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
Received on Tue Jun 29 03:13:00 2004