SteveKing wrote:
>>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 know that. But this worked (still does) on the 1.0.x branch. There the
> library get's added to the projects link dependencies by the script.
I believe that is because Apache (aprutil) never tried to link in BDB
before, but I'm not sure until I take a closer look. Did you run the
w32locatedb.pl script that tweaks Apache to look for BDB?
>
>
>>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.
>
>
> Building Apache first means using the *.dsp files and convert them first.
> That will work, yes. But so does the "-t dsp" part of the script.
>
The currently generated dsp's (Apache's work fine) actually will not get
converted correctly -- VSNet's converter doesn't handle the resource
compiler's quoting rules correctly and so the exe's with resources fail
to build. At least that is what happened the last time I tried them
which was a while ago.
>
>>I use VSNet2003 and I don't see this problem -- it converts the
>>VSNet2002 project and solutions fine. The problem with adding another
>
>
> It does this _only_ if you start the IDE and load the solution file.
> But if you try to do this:
> devenv subversion_vcnet.sln /useenv /build release /project "__ALL__"
> it doesn't work because it stops with an error message that the
> solution/project files first have to be converted. And converting from the
> command line is not possible (believe me: I searched all docs, googled for
> two days).
> But that's not a real problem. As I said I can work around that by tweaking
> that version number in the solution file myself.
Right, if you don't tweak the template manually you have to invoke the
IDE to convert it -- I agree it's annoying and makes automated scripts
for building more difficult.
>
>
>>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.
>
>
> Oh no! Please don't. If you do that, then I can forget having a build script
> for TSVN because I then _must_ build Subversion "manually" first, i.e. not
> from the command line.
>
>
> I found another "bug" in the "-t vcproj" build:
> if you do a /rebuild instead of just a /build, then the
> /build/win32/build_neon.bat file get's deleted before the actual build
> (seems the "temp" pattern specified includes *.bat). That means that a
> /rebuild is not possible at all. Only normal builds work.
>
>
Hmm, that is probably true of the dsp projects too, then.
If anyone has ideas on how to handle the various project/solution file
format problem gracefully, feel free to chime in...It just seems like an
eternal maintenance problem to try and keep up with every new format
that comes with every new version of the IDE -- the version number
changes are not the only differences, although just tweaking that does
seem to work.
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 15:04:22 2004