[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))

From: Tim Van Holder <tim.van.holder_at_telenet.be>
Date: 2006-01-05 09:29:54 CET

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

This is an archived mail posted to the Subversion Dev mailing list.