On 12/31/05, Tim Van Holder <tim.van.holder@telenet.be> wrote:
> [if I had known a 1.3 release was imminent, I'd have sent this earlier]
AFAIK, none of the newer VS2005 changes are in 1.3 anyway. The basic
VS2005 support has been working fine for me for a long time, though --
the newer changes just help with msbuild and VCExpress.
>
> 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).
What exactly doesn't work? It's working fine for me --
double-clicking, right click and open etc. Is it only if you have
multiple versions of VS installed? The newline is there because that
is how new solution files look when I create them directly from VS2005
-- however, I see now that there is some binary stuff on the front of
it: 0xEFBBBF. I guess that is some sort of encoding marker? Do yours
have that? As you say, if I just drop the newline then the icon
changes to the new one with the little 8 which I suppose means the
shell extension recognizes it correctly. But now I'm wondering if we
should include the binary marker, too...
>
> 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.
The build system is fairly complicated due to all of Subversion's
dependencies and attempts to work with multiple versions of those
dependencies -- trying to get everything right in all conditions is
pretty difficult, but if you have patches feel free to post them and
we'll try to get them applied as appropriate.
>
> 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.
Yes, it was a temporary measure to include our own vcproj files for
apr and it is not at all optimal. Hopefully when apr's generator
support is complete we can dump them and just use it. I have no idea
what the status of that is, though.
> One issue is that apr.h already defines _CRT_SECURE_NO_DEPRECATE,
> causing lots of warnings about a duplicate definition of that macro.
Hmm, you should only get warnings if the definition is different,
shouldn't you? And the apr I have from Apache 2.0.55 doesn't have
those set which is why they were added. Are you using a newer apr?
> 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?
I believe it is intended to simplify building -- so that the user
doesn't have to fetch and build apr separately and then build
Subversion. I wouldn't cry if it was changed, but I'm not sure how
the other devs feel.
> Also, since neon and apr are in a subversion repository, why not include
> them as externals?
Externals in a working copy? I'm not sure what you mean if you mean
inside a release tarball. If you mean in a checked-out working copy,
then folks may already have a different apr and neon installed and not
want to pull all that down for nothing. Personally, I don't have any
strong feelings for or against it, though.
>
> 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).
Yes, this is a known zlib issue and a patched asm is available and
should be included in the next zlib release.
Thanks!
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 1 02:43:22 2006