D.J. Heap wrote:
> On 1/1/06, Tim Van Holder <tim.van.holder@telenet.be> wrote:
> [snip]
>
>>Yes, but it's a warning for every single file that uses apr.h, masking
>>pretty much anything else it might complain about.
>>The apr I am using is the HEAD of branches/0.9.x.
>
> So what did you do to fix it? Remove the preprocessor defines from
> just the apr projects or from the Subversion projects too? We need it
> defined in Subversion, as well. It seems like apr.h should be testing
I added an "#if !defined" around the #define in apr.hw.
I also replaced their #pragma warning (which is indicated as their
solution to the 'POSIX name deprecated' warning) with a similar
#if/#define/#endif for _CRT_NONSTDC_NO_DEPRECATE, although I'm not sure
that that's needed (thy may have had a specific reason for using the
#pragma instead).
> it before just defining it, and it also seems like the compiler
> shouldn't complain if the definitions are identical, shouldn't it?
That's what I thought too - apr.h even duplicates the #define and
there's no compiler warning from that, only for the first one.
As it turns out, the /D command line option of the compiler is
documented as defaulting to a value of 1.
So the predefinition in the project file is
#define FOO 1
while apr.h uses
#define FOO
so the definition isn't identical.
Perhaps using _CRT_SECURE_NO_DEPRECATE= (with the added '=') in the list
of additional preprocessor defines of the subversion projects also
makes the warnings go away - I'll check when I get home from work
tonight.
>>Oh, I'm not sure if the built apr and db DLLs are supposed to end up in
>>the svn build dir or not, but currently they don't. This means that
>
> [snip]
>
> I don't believe they are supposed to currently -- Brane has a python
> script to gather them all together into a binary release tree and zip
> file -- make_dist.py in the build/win32 directory? If we did make it
> part of the build process, then we'd need to do it for the generated
> .dsp projects as well. But that would be a handy addition, IMO.
I'm a bit hesitant to install VC6 on my machine, but I'll see what I
can do. VC6 also post-build rules and predefined vars, so I doubt the
rule will differ substantially.
>>By the way, the reason i'm building subversion from sources is because
>>I want to try to build .NET bindings for it, and possibly an SCC
>>plugin. These are mainly as exercises for myself (to get some Managed
>>C++ experience), but if I get the .NET bindings in a suitable functional
>>state, would that be something you're interested in adding to the
>>subversion/bindings tree?
>>
>
> I know I would be interested (although I couldn't commit to help
> maintaining it much) and we've had several inquiries in the past. I
> think people have been pointed to swig and AnkhSvn
> (http://ankhsvn.tigris.org) in the past. I'm not sure what it would
> take to host it in the bindings tree -- at least a committed
> maintainer or two and probably some solid justification as to why swig
> wasn't used.
I only have 2 reasons for not using swig:
- I have absolutely no experience with swig
- from what I can tell, it maps everything directly to static functions
of a class, with no name changes. This makes it fit in very badly
with other .NET class libraries (naming conventions, etc.)
But I'll look into it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 5 09:31:23 2006