[if I had known a 1.3 release was imminent, I'd have sent this earlier]
D.J. Heap wrote:
> On 12/26/05, Tim Van Holder <tim.van.holder@telenet.be> wrote:
>
>>Hi,
>>
>>the VS.NET generator currently assumes that simply having the correct
>>file version (7.00/8.00/9.00) in the .sln file is enough. For VS2005,
>>this is not entirely true.
>>While the IDE is capable of opening such .sln file, they cannot be
>>opened from the shell; .sln files are scanned for content by a shell
>>extension so that the correct version of VS is launched for that
>>solution, allowing VS.NET2002/VS.NET2003/VS2005 to be installed side
>>by side. For some odd reason, that shell extension requires .sln files
>>to start with
>
> [snip]
>
> I committed a tweaked version of this patch in r17940 -- trunk support
> for VC2005 has evolved since your patch was made. It doesn't change
> the output for older versions since VC2005 has it's own solution
> template now.
>
> Thanks!
Unfortunately, an excess newline snuck into the start of that template,
again breaking recognition as a valid 2005 solution file in the shell.
(Also, as a minor aside, VS2005 is no longer branded as "Visual
Studio.NET", so it would be nice if gen_win.py was adjusted
accordingly).
Cygwin's perl is in my PATH before the ActiveState one; this prevents
the Perl version from being found. It's easy to work around, but it
would be even nicer if the script detected a cygwin perl and warned
about it specifically (finding /usr/xxx paths instead of X:/foo should
be enough of a heuristic). Alternatively, instead of using the first
perl in the PATH, it could walk the path looking for a usable perl
(kinda like how a autoconf-based configure script does it).
Berkeley DB support requires include and lib directories under the
directory given to --with-berkeley-db; this basically requires an
installed version (passing the Visual C directory), as the source
tree has neither directory (it has dbinc and build_win32/Release,
at least for version 4.4).
In addition, a debug build of subversion tries to link with a debug
library of Berkeley DB, while the configuration only checks whether
a release build is available - it's not obvious to me that someone
who wants a debug version of subversion automatically wants a debug
version of libdb.
With a freshly checked-out neon, I get the warning about not being able
to determine its version. While using .version is probably the best way
of finding it, a fallback in case .version is missing could be
grep "^Changes in release " <neon>/NEWS | head -1 \
| sed -e 's/^.* //' -e 's/:$//'
This still leaves the problem that the neon svn repository does not
include config.hw either, but that was created from config.hw.in
easily enough.
I also ran into some problems with how apr projects are handled. While
apr does not provide VS.NET/VS2005 projects, it does provide projects
for Visual Studio 6, which VS.NET/VS2005 are quite capable of upgrading.
In my case, I had already successfully built apr/apr-iconv/apr-utils,
so it felt odd that the subversion solution included its own version.
One issue is that apr.h already defines _CRT_SECURE_NO_DEPRECATE,
causing lots of warnings about a duplicate definition of that macro.
With non-0.9.x-branch trees of apr, things go off the rails completely
(but since only 0.9.x is officially supported that's to be expected).
Is there a particular reason why for apr it's not just about finding the
lib and the headers?
Also, since neon and apr are in a subversion repository, why not include
them as externals?
Zlib building is broken for VS2005 - all sorts of deprecated C compiler
flags are used (warnings only, but still), and zlib 1.2.3 ships with an
inffas32.asm that cannot be compiled by the ml.exe that ships with
VS2005. Again a case where it's perfectly possible to build with the
upgraded project resulting from opening the included VC6 workspace
in VS2005 (and not using the ASM core).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 31 16:21:20 2005