VS2005 configuration/build issues (was Re: Minor issue with VS.NET solution file generation (trunk))

[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.holdertelenet.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

Tim Van Holder wrote:

> 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).

Windows uses the first exe it find in the path. You can't
change that.
The only way to work around that would be to read the PATH
variable and 
try all paths in it on your own.

> 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).

Version 4.4 of BDB hasn't been tested thoroughly with
Subversion yet. 
I'd stick with 4.3 if I were you.

> 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.

If you link a release library with a debug build, you end up
with linker 
warnings about LIBC or LIBCD, that's because release builds
are usually 
linked against LIBC, while debug builds are linked against
LIBCD. That's 
why you should (if you can) always link debug builds with
debug libs and 
not mix those.

> 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/:$//'

Not everyone has grep installed. If you download the source
tarball of 
neon, that file is included there.

> 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).

Are you sure that 0.9.x defines _CRT_SECURE_NO_DEPRECATE? My
apr.h 
doesn't define that.

> 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).

If you want, you can build zlib without ASM support (just
make sure 
Subversion doesn't find msasm in the PATH).
Or, you can use the patched inffas32.asm file here:
http://tortoisesvn.tigris.org/svn/tort
oisesvn/trunk/ext/build/inffas32.asm
instead. That one will build just fine.

Stefan
-- 
        ___
   oo  // \      "De Chelonian Mobile"
  (_,/ _/      TortoiseSVN
     _/__/>    The coolest Interface to (Sub)Version
Control
    /_/   _     http://tortoisesvn.tigr
is.org


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 12/31/05, Tim Van Holder <tim.van.holdertelenet.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

D.J. Heap wrote:
> On 12/31/05, Tim Van Holder <tim.van.holdertelenet.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?

Index: generator/vc2005_sln.ezt
============================================================
=======
--- generator/vc2005_sln.ezt	(revision 17949)
+++ generator/vc2005_sln.ezt	(working copy)
 -1,4
+1,3 
-
 Microsoft Visual Studio Solution File, Format Version
[version]
 # Visual Studio 2005
 [for
targets]Project("
") = "[targets.name]",
"[targets.path]", "[targets.guid]"
Index: generator/vcnet_vcproj.ezt
============================================================
=======
--- generator/vcnet_vcproj.ezt	(revision 17949)
+++ generator/vcnet_vcproj.ezt	(working copy)
 -10,8
+10,8 
 	<Configurations>
 [for platforms][for configs]		<Configuration
 			Name="[configs.name]|[platforms]"
-			OutputDirectory="......[configs.name][target.ou
tput_dir]"
-			IntermediateDirectory="......[configs.name][tar
get.intermediate_dir]"
+			OutputDirectory="$(SolutionDir)$(ConfigurationName)
[target.output_dir]"
+			IntermediateDirectory="$(SolutionDir)$(Configuratio
nName)[target.intermediate_dir]"
 			ConfigurationType="[target_type]"[is
configs.name "Release"]
 			WholeProgramOptimization="FALSE"[end]>
 			<Tool
 -66,7
+66,11 
 [end]			<Tool
 				Name="VCMIDLTool"/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"[is target_type
"1"]
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			[end][is target_type "2"]
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			[end]/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
Index: generator/libaprutil.vcproj.ezt
============================================================
=======
--- generator/libaprutil.vcproj.ezt	(revision 17949)
+++ generator/libaprutil.vcproj.ezt	(working copy)
 -54,7
+54,9 
 				TypeLibraryName=".Debug/libaprutil.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
 -115,7
+117,9 
 				TypeLibraryName=".Release/libaprutil.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
Index: generator/libapriconv.vcproj.ezt
============================================================
=======
--- generator/libapriconv.vcproj.ezt	(revision 17949)
+++ generator/libapriconv.vcproj.ezt	(working copy)
 -53,7
+53,9 
 				TypeLibraryName=".Debug/libapriconv.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
 -113,7
+115,9 
 				TypeLibraryName=".Release/libapriconv.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
Index: generator/libapr.vcproj.ezt
============================================================
=======
--- generator/libapr.vcproj.ezt	(revision 17949)
+++ generator/libapr.vcproj.ezt	(working copy)
 -54,7
+54,9 
 				TypeLibraryName=".Debug/libapr.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool
 -115,7
+117,9 
 				TypeLibraryName=".Release/libapr.tlb"
 				HeaderFileName=""/>
 			<Tool
-				Name="VCPostBuildEventTool"/>
+				Name="VCPostBuildEventTool"
+				CommandLine="mkdir
&quot;$(SolutionDir)$(ConfigurationName)&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;mkdir
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL 2&gt;&amp;1&#x0D;&#x0A;copy
&quot;$(TargetPath)&quot;
&quot;$(SolutionDir)$(ConfigurationName)bin&quot;
&gt;NUL&#x0D;&#x0A;"
+			/>
 			<Tool
 				Name="VCPreBuildEventTool"/>
 			<Tool

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 12/31/05, D.J. Heap <djheapgmail.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

Carlos Alberto Costa Beppler wrote:
> On 12/31/05, D.J. Heap <djheapgmail.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

> 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.

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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

On 1/1/06, Tim Van Holder <tim.van.holdertelenet.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org

D.J. Heap wrote:
> On 1/1/06, Tim Van Holder <tim.van.holdertelenet.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-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org