SteveKing wrote:
> Ben Collins-Sussman wrote:
>
> [snip]
>
>> Perhaps you should rebuild apache first?
>
>
> I usually don't build mod_dav_svn, so building apache is not necessary.
>
>> Is "-t vcproj" for VS.NET? I was using "-t dsp" for VC6. Maybe your
>> problem is unique to VS.NET.
>
>
> Yes. That's the problem. I tried the "-t dsp" switch and then converted
> the project files with VS.NET - there the library is added and I can
> compile.
>
> So the "-t vcproj" build is definitely broken!
> Can someone who knows perl please fix that? I really need to compile
> Subversion or I can't work on TSVN anymore :(
The root of the problem is that Apache doesn't ship vcproj files, only
dsp's. So, we have some 'pre-converted' vcproj files that we just copy
over to the apr directories and tell the solution to use those. Icky.
I think the idea was that eventually Apache would ship vcproj's or use a
generator or something, but that hasn't happened yet.
I'm not sure exactly what is wrong (Apache seems to want BDB now when it
never did before), but if you build Apache first it should work since
the projects will be up to date and it won't bother building using our
project files.
I'll look into it deeper when I can, but it is building for me as long
as I build Apache first.
>
> And if we're on the subject (the gen-make.py script):
> To compile Subversion with VS.NET2003 from the command line (or from
> within a build script) the .sln file doesn't work. The reason for that
> is that the generated .sln file contains the following line on top:
> Microsoft Visual Studio Solution File, Format Version 7.00
> but VS.NET2003 needs the line to be
> Microsoft Visual Studio Solution File, Format Version 8.00
>
> For the TSVN build script I "fixed" that by overwriting the file
> vcnet_sln.ezt in the Subversion build folder with a version which has
> the correct line in it. But it would be great if the gen-make.py script
> had another option "-t vcproj2003" which did that automatically.
I use VSNet2003 and I don't see this problem -- it converts the
VSNet2002 project and solutions fine. The problem with adding another
option for a new project file format is that it will never end. MS
already has 3 formats and VS.Next (Whidbey) introduces yet another. Yay.
I think we may be better off redoing how our version resource
definitions are handled so that we can ditch the vcproj support entirely
and just let VS convert dsp's (even Whidbey converts dsps) -- the
resource definitions are the only reason VSNet screws up when it
converts Subversion dsp files.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 22 03:14:32 2004