You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "D.J. Heap" <dj...@gmail.com> on 2006/01/01 01:42:44 UTC
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
On 12/31/05, Tim Van Holder <ti...@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
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by "D.J. Heap" <dj...@gmail.com>.
On 2/2/06, Tim Van Holder <ti...@telenet.be> wrote:
[snip]
> Yes.
> Removing the per-file settings entirely would be desirable as well (all
> files have the same settings anyway, so duplicating them everywhere only
> makes the projects larger and makes it harder to try different flags).
>
Thanks! I committed the patch (minus the awk/gawk changes) in r18323.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Tim Van Holder <ti...@telenet.be>.
D.J. Heap wrote:
> On 1/9/06, Tim Van Holder <ti...@telenet.be> wrote:
> [snip]
>
>>Sorry, I had forgotten to retest anything other than the apr projects.
>>
>>Now this is very odd - I just tried building libsvn_diff with the
>>changed preprocessor settings, and it builds without the redefinition
>>warnings (and with the warnings if the standard defines are used).
>>Ahh - I see now - every .c file in the apr projects has its own preproc
>>settings, overriding the global settings. Since they all specify the
>>same flags, I removed the per-file settings, and that clears the
>>warnings up.
>
> So, we just need to change the DEPRECATE defines in the project files
> to have the = on the end to silence the redefinition warnings you were
> getting, right?
>
> DJ
Yes.
Removing the per-file settings entirely would be desirable as well (all
files have the same settings anyway, so duplicating them everywhere only
makes the projects larger and makes it harder to try different flags).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/9/06, Tim Van Holder <ti...@telenet.be> wrote:
[snip]
> Sorry, I had forgotten to retest anything other than the apr projects.
>
> Now this is very odd - I just tried building libsvn_diff with the
> changed preprocessor settings, and it builds without the redefinition
> warnings (and with the warnings if the standard defines are used).
> Ahh - I see now - every .c file in the apr projects has its own preproc
> settings, overriding the global settings. Since they all specify the
> same flags, I removed the per-file settings, and that clears the
> warnings up.
So, we just need to change the DEPRECATE defines in the project files
to have the = on the end to silence the redefinition warnings you were
getting, right?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/7/06, Tim Van Holder <ti...@telenet.be> wrote:
[snip]
> Putting "_CRT_SECURE_NO_DEPRECATE=;_CRT_NONSTDC_NO_DEPRECATE="
> in the preprocessor settings for apr does not avoid the "macro
> redefinition" warning. So either the svn config process needs to
> exclude them from the apr projects it generates, or the apr folks
> need to put "#if !defined()" guards around their definition.
>
Is it just the apr projects that get all the warnings? The Subversion
projects don't?
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Tim Van Holder <ti...@telenet.be>.
D.J. Heap wrote:
> On 1/5/06, Tim Van Holder <ti...@telenet.be> wrote:
> [snip]
>
>>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.
>
> Thanks.
Putting "_CRT_SECURE_NO_DEPRECATE=;_CRT_NONSTDC_NO_DEPRECATE="
in the preprocessor settings for apr does not avoid the "macro
redefinition" warning. So either the svn config process needs to
exclude them from the apr projects it generates, or the apr folks
need to put "#if !defined()" guards around their definition.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/5/06, Tim Van Holder <ti...@telenet.be> wrote:
[snip]
> 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.
Thanks.
[snip]
> 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.
>
I'm not a swig expert, but I think the bindings come in two layers --
a low level layer directly from swig that just wraps functions and
stuff, and then a (partially?) hand-crafted higher level layer that is
customized more to the language. At least, that is my understanding
based on conversations I've seen here.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Tim Van Holder <ti...@telenet.be>.
D.J. Heap wrote:
> On 1/1/06, Tim Van Holder <ti...@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
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by "D.J. Heap" <dj...@gmail.com>.
On 1/1/06, Tim Van Holder <ti...@telenet.be> wrote:
[snip]
> Yes, I have VS.NET 2003 and VS2005 both installed, and if there is no
> version indication (7/7.1/8) on the icon, double-clicking does nothing.
> It's possible that if you only have one version installed, it will
> always use that to open every .sln file, regardless of whether it's
> recognized or not.
> The binary marker is probably to indicate a UTF-8 file, so isn't
> required as such (VS supports UTF-8 just fine without that marker).
Ok, I'll just remove the blank line on trunk.
>
> 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
it before just defining it, and it also seems like the compiler
shouldn't complain if the definitions are identical, shouldn't it?
>
> 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.
>
> 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.
Thanks!
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Tim Van Holder <ti...@telenet.be>.
D.J. Heap wrote:
> On 12/31/05, Tim Van Holder <ti...@telenet.be> wrote:
>
>>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...
Yes, I have VS.NET 2003 and VS2005 both installed, and if there is no
version indication (7/7.1/8) on the icon, double-clicking does nothing.
It's possible that if you only have one version installed, it will
always use that to open every .sln file, regardless of whether it's
recognized or not.
The binary marker is probably to indicate a UTF-8 file, so isn't
required as such (VS supports UTF-8 just fine without that marker).
> 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'll look into it - I'm not very comfortable with Python (yet), but
I'll try :-)
>>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?
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.
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
it will use installed versions instead. For db this isn't an issue,
since the build process expects an installed db anyway.
But with apr, it means that svn will not typically be runnable from
its build tree (although it may pick up the dlls from an installed
svn because they're in the path).
Attached is a patch that adjusts the build process to copy all DLLs
and .exes to a bin directory in the output tree, and tries to avoid
using hardcoded paths in favor of VS macros. It currently uses
post-build events on each of the particular projects, but perhaps it
could be put in the __ALL__ project instead (but that would require
using hardcoded paths).
The iconv modules are not currently copied, because they're makefile
projects which cannot have post-build events. Perhaps an empty
project (libapriconv_and_modules?) could be added for that purpose;
then again, setting APR_ICONV_PATH to the build tree is probably enough
to use the ones from the build.
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?
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Michael Sweet <mi...@easysw.com>.
Carlos Alberto Costa Beppler wrote:
>> Given the usage of US-ASCII filenames and UTF-8 encoding, is the BOM
>> even necessary?
>>
> Are you sure that filenames are US-ASCII only?
>
> Here in Brasil many tend to use non ASCII characters specially on
> "documentation" files.
But these are the templates for the Subversion project files, which
reference the Subversion source files, which only use US-ASCII.
In the general case, this is not strictly true, but for the Subversion
project it doesn't seem to make sense to add these (unused and
unnecessary) UTF-8 characters to an otherwise US-ASCII XML file.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
> Given the usage of US-ASCII filenames and UTF-8 encoding, is the BOM
> even necessary?
>
Are you sure that filenames are US-ASCII only?
Here in Brasil many tend to use non ASCII characters specially on
"documentation" files.
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET
solution file generation (trunk))
Posted by Michael Sweet <mi...@easysw.com>.
Carlos Alberto Costa Beppler wrote:
> On 12/31/05, D.J. Heap <dj...@gmail.com> wrote:
>> -- 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?
>
> This is the unicode byte order mark for utf-8 files. See
> http://www.unicode.org/faq/utf_bom.html#25
Given the usage of US-ASCII filenames and UTF-8 encoding, is the BOM
even necessary?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))
Posted by Carlos Alberto Costa Beppler <be...@gmail.com>.
On 12/31/05, D.J. Heap <dj...@gmail.com> wrote:
> -- 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?
This is the unicode byte order mark for utf-8 files. See
http://www.unicode.org/faq/utf_bom.html#25