[PATCH 1/2] Make generated MSVC solution file open from Windows Explorer

 From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <redacted>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer

In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.

Signed-off-by: Sebastian Schuberth <redacted>
---
  contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
  1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm

@@ -131,6 +131,7 @@ sub createLibProject {
      $includes =~ s/-I//g;
      mkdir "$target" || die "Could not create the directory $target for lib project!\n";
      open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+    binmode F, ":crlf";
      print F << "EOM";
  <?xml version="1.0" encoding = "Windows-1252"?>
  <VisualStudioProject

@@ -353,6 +354,7 @@ sub createAppProject {
      $includes =~ s/-I//g;
      mkdir "$target" || die "Could not create the directory $target for lib project!\n";
      open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+    binmode F, ":crlf";
      print F << "EOM";
  <?xml version="1.0" encoding = "Windows-1252"?>
  <VisualStudioProject

@@ -537,7 +539,7 @@ sub createGlueProject {
      print "Generate solutions file\n";
      $rel_dir = "..\\$rel_dir";
      $rel_dir =~ s/\//\\/g;
-    my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+    my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
      my $SLN_PRE  = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
      my $SLN_POST = "\nEndProject\n";
  

@@ -560,6 +562,7 @@ sub createGlueProject {
      @apps = @tmp;
  
      open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+    binmode F, ":crlf";
      print F "$SLN_HEAD";
      foreach (@libs) {
          my $libname = $_;

-- 
1.6.4.msysgit.0

Sebastian Schuberth [off-list ref] wrote:

From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <redacted>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer

In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.

Something is wrong with both patches; neither applies.  It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

-- 
Shawn.

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

Sebastian Schuberth [off-list ref] wrote:

quoted

In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.

Something is wrong with both patches; neither applies.  It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

Besides, there is PERLIO environment variable. Try setting it to
PERLIO=':perlio'

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

Sebastian Schuberth [off-list ref] wrote:

quoted

From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <redacted>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer

In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.

Something is wrong with both patches; neither applies.  It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

Hmm, the patches apply fine onto master for me.

As a side note, I've never liked sending patches via mail. It just
feels like writing a text on a computer just to print it out, scan in
the sheet again, and then sending the scanned image as an attachment
via email. Isn't there a better way to contribute patches to Git, like
pushing to a mob branch as for the msysGit project?

-- 
Sebastian Schuberth

On Sat, Sep 26, 2009 at 00:11, Alex Riesen [off-list ref] wrote:

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Sebastian Schuberth [off-list ref] wrote:

quoted

In order to be able to open the generated solution file by double-clicking it
in Windows Explorer, all project files need to use DOS line-endings and a
comment about the Visual Studio version needs to be added to the header of the
solution file. This also fixes the icon that is displayed for the solution file
in Windows Explorer.
Note that opening the solution file from a running instance of Visual Studio
already worked before.

Something is wrong with both patches; neither applies.  It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

Besides, there is PERLIO environment variable. Try setting it to
PERLIO=':perlio'

But I don't feel like using it here would be the right thing to do.
Visual Studio project files should never ever be written out with Unix
line-endings, not even if someone created them under Unix. So instead
of relying on the environment variable to be set correctly, I believe
it's better to always enforce the correct line-endings here.

-- 
Sebastian Schuberth

Sebastian Schuberth [off-list ref] wrote:

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Something is wrong with both patches; neither applies. ??It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

Hmm, the patches apply fine onto master for me.

After going through your client and the GMane email gateway?
Or before you pasted it into the message?
 

As a side note, I've never liked sending patches via mail. It just
feels like writing a text on a computer just to print it out, scan in
the sheet again, and then sending the scanned image as an attachment
via email. Isn't there a better way to contribute patches to Git, like
pushing to a mob branch as for the msysGit project?

It works fine, so long as the tools in the chain leave the body
of the message alone and don't try to outsmart the human who put
it there.

The git project in particular as rules about only applying patches
off the mailing list, because then all contributions are in a
permanent, public archive.  Its also the form of communication most
contributors prefer for code reviews.

-- 
Shawn.

On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce [off-list ref] wrote:

Sebastian Schuberth [off-list ref] wrote:

quoted

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Something is wrong with both patches; neither applies. ??It looks
to be an issue with whitespace, like context lines are gaining an
extra space at the start of the line.

Hmm, the patches apply fine onto master for me.

After going through your client and the GMane email gateway?
Or before you pasted it into the message?

Both. As a test for the first, I've copied & pasted my mail as it
appears for me in gmane.comp.version-control.git to a new file and
successfully applied that file via "git apply". I had to do it this
way, as on Windows I cannot really use "git am" with Thunderbird.

-- 
Sebastian Schuberth

Sebastian Schuberth [off-list ref] wrote:

On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce [off-list ref] wrote:

quoted

Sebastian Schuberth [off-list ref] wrote:

quoted

On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Something is wrong with both patches; neither applies.

Hmm, the patches apply fine onto master for me.

After going through your client and the GMane email gateway?
Or before you pasted it into the message?

Both. As a test for the first, I've copied & pasted my mail as it
appears for me in gmane.comp.version-control.git to a new file and
successfully applied that file via "git apply". I had to do it this
way, as on Windows I cannot really use "git am" with Thunderbird.

Odd.  If I copy and paste from Thunderbird, its fine.  But if I
save the body out as an attachment from mutt, it fails.

I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format.  It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.

Next time, don't include the first From line?

-- 
Shawn.

On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce [off-list ref] wrote:

Odd.  If I copy and paste from Thunderbird, its fine.  But if I
save the body out as an attachment from mutt, it fails.

I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format.  It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.

Next time, don't include the first From line?

Will try. So what about these two patches? Should I re-send them with
the first "From" stripped?

Or will *.patch files that are attached to emails, instead of sending
the patch inline, be accepted?

-- 
Sebastian Schuberth

Sebastian Schuberth [off-list ref] wrote:

On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Odd. ??If I copy and paste from Thunderbird, its fine. ??But if I
save the body out as an attachment from mutt, it fails.

I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format. ??It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.

Next time, don't include the first From line?

Will try. So what about these two patches? Should I re-send them with
the first "From" stripped?

Might be worth trying.  I honestly don't know why they were munged
before.
 

Or will *.patch files that are attached to emails, instead of sending
the patch inline, be accepted?

We really don't like them, because you can't comment on them inline
easily.  Sometimes they are acceptable for translation files when
the character encoding otherwise gets really broken.

-- 
Shawn.

2009/9/26 Sebastian Schuberth [off-list ref]:

On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce [off-list ref] wrote:

quoted

Odd.  If I copy and paste from Thunderbird, its fine.  But if I
save the body out as an attachment from mutt, it fails.

I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format.  It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.

FYI: the Thunderbird version included this header:
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed

The format=flowed part shows that Thunderbird is reformatting
whitespace. You can disable that:
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email

'flowed' is a lossy transformation of text, so git won't attempt to
fix patches that have  been mangled that way. There's a longer
explanation from Junio here:
http://kerneltrap.org/mailarchive/git/2008/2/15/867294

Hope this helps,
Baz

quoted

Next time, don't include the first From line?

Will try. So what about these two patches? Should I re-send them with
the first "From" stripped?

Or will *.patch files that are attached to emails, instead of sending
the patch inline, be accepted?

--
Sebastian Schuberth
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

The generated solution file was valid, but not exactly in the way the
2008 IDE wanted them, so the IDE would query to save the solution file
even though the user never touched the solution/projects.
These two patches ensures that the solution file is in the way the IDE
wants them, so we avoid the naging.

The two patches didn't apply for me in the way they were sent. I
manually applied them ontop of master, and added an Acked-by.

Thanks!

Sebastian Schuberth (2):
  Make generated MSVC solution file open from Windows Explorer
  Make just opening the generated MSVC solution file not modify it

 contrib/buildsystems/Generators/Vcproj.pm |   47 +++++++++-------------------
 1 files changed, 15 insertions(+), 32 deletions(-)

From: Sebastian Schuberth <redacted>

In order to be able to open the generated solution file by double-
clicking it in Windows Explorer, all project files need to use DOS
line-endings and a comment about the Visual Studio version needs to
be added to the header of the solution file. This also fixes the icon
that is displayed for the solution file in Windows Explorer.
Note that opening the solution file from a running instance of Visual
Studio already worked before.

Signed-off-by: Sebastian Schuberth <redacted>
Acked-by: Marius Storm-Olsen <redacted>
---
 contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 00ec0c1..50daa03 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm

@@ -131,6 +131,7 @@ sub createLibProject {
     $includes =~ s/-I//g;
     mkdir "$target" || die "Could not create the directory $target for lib project!\n";
     open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+    binmode F, ":crlf";
     print F << "EOM";
 <?xml version="1.0" encoding = "Windows-1252"?>
 <VisualStudioProject

@@ -353,6 +354,7 @@ sub createAppProject {
     $includes =~ s/-I//g;
     mkdir "$target" || die "Could not create the directory $target for lib project!\n";
     open F, ">$target/$target.vcproj" || die "Could not open $target/$target.pro for writing!\n";
+    binmode F, ":crlf";
     print F << "EOM";
 <?xml version="1.0" encoding = "Windows-1252"?>
 <VisualStudioProject

@@ -537,7 +539,7 @@ sub createGlueProject {
     print "Generate solutions file\n";
     $rel_dir = "..\\$rel_dir";
     $rel_dir =~ s/\//\\/g;
-    my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n";
+    my $SLN_HEAD = "Microsoft Visual Studio Solution File, Format Version 10.00\n# Visual Studio 2008\n";
     my $SLN_PRE  = "Project(\"{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}\") = ";
     my $SLN_POST = "\nEndProject\n";
 

@@ -560,6 +562,7 @@ sub createGlueProject {
     @apps = @tmp;
 
     open F, ">git.sln" || die "Could not open git.sln for writing!\n";
+    binmode F, ":crlf";
     print F "$SLN_HEAD";
     foreach (@libs) {
         my $libname = $_;

-- 
1.6.5.rc2.177.ga9dd6

From: Sebastian Schuberth <redacted>

The format of the generated MSVC solution file is fixed in a way that
just opening it in Visual Studio and immediately closing it again
without performing any modifications does not trigger a prompt to save
the solution file. This behavior was caused by several minor
incompatibilities between the generated file and what Visual Studio
2008 expected, so Visual Studio transparently fixed the file format,
marking it internally as modified.

Signed-off-by: Sebastian Schuberth <redacted>
Acked-by: Marius Storm-Olsen <redacted>
---
 contrib/buildsystems/Generators/Vcproj.pm |   42 +++++++---------------------
 1 files changed, 11 insertions(+), 31 deletions(-)

diff --git a/contrib/buildsystems/Generators/Vcproj.pm b/contrib/buildsystems/Generators/Vcproj.pm
index 50daa03..d53ff2c 100644
--- a/contrib/buildsystems/Generators/Vcproj.pm
+++ b/contrib/buildsystems/Generators/Vcproj.pm

@@ -571,45 +571,29 @@ sub createGlueProject {
         print F "\"${libname}\", \"${libname}\\${libname}.vcproj\", \"${uuid}\"";
         print F "$SLN_POST";
     }
+    my $uuid_libgit = $build_structure{"LIBS_libgit_GUID"};
+    my $uuid_xdiff_lib = $build_structure{"LIBS_xdiff_lib_GUID"};
     foreach (@apps) {
         my $appname = $_;
         my $uuid = $build_structure{"APPS_${appname}_GUID"};
         print F "$SLN_PRE";
-        print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"";
+        print F "\"${appname}\", \"${appname}\\${appname}.vcproj\", \"${uuid}\"\n";
+        print F "	ProjectSection(ProjectDependencies) = postProject\n";
+        print F "		${uuid_libgit} = ${uuid_libgit}\n";
+        print F "		${uuid_xdiff_lib} = ${uuid_xdiff_lib}\n";
+        print F "	EndProjectSection";
         print F "$SLN_POST";
     }
 
     print F << "EOM";
 Global
-	GlobalSection(SolutionConfiguration) = preSolution
-		ConfigName.0 = Debug|Win32
-		ConfigName.1 = Release|Win32
+	GlobalSection(SolutionConfigurationPlatforms) = preSolution
+		Debug|Win32 = Debug|Win32
+		Release|Win32 = Release|Win32
 	EndGlobalSection
-	GlobalSection(ProjectDependencies) = postSolution
 EOM
-    foreach (@{$build_structure{"APPS"}}) {
-        my $appname = $_;
-        my $appname_clean = $_;
-        $appname_clean =~ s/\//_/g;
-        $appname_clean =~ s/\.exe//;
-
-        my $uuid = $build_structure{"APPS_${appname_clean}_GUID"};
-        my $dep_index = 0;
-        foreach(@{$build_structure{"APPS_${appname}_LIBS"}}) {
-            my $libname = $_;
-            $libname =~ s/\//_/g;
-            $libname =~ s/\.(a|lib)//;
-            my $libuuid = $build_structure{"LIBS_${libname}_GUID"};
-            if (defined $libuuid) {
-                print F "\t\t${uuid}.${dep_index} = ${libuuid}\n";
-                $dep_index += 1;
-            }
-        }
-    }
-
     print F << "EOM";
-	EndGlobalSection
-	GlobalSection(ProjectConfiguration) = postSolution
+	GlobalSection(ProjectConfigurationPlatforms) = postSolution
 EOM
     foreach (@libs) {
         my $libname = $_;

@@ -630,10 +614,6 @@ EOM
 
     print F << "EOM";
 	EndGlobalSection
-	GlobalSection(ExtensibilityGlobals) = postSolution
-	EndGlobalSection
-	GlobalSection(ExtensibilityAddIns) = postSolution
-	EndGlobalSection
 EndGlobal
 EOM
     close F;

-- 
1.6.5.rc2.177.ga9dd6

The two patches didn't apply for me in the way they were sent. I
manually applied them ontop of master, and added an Acked-by.

Thanks for fixing my patches, Marius!

-- 
Sebastian Schuberth

On Mon, Sep 28, 2009 at 12:36, Baz [off-list ref] wrote:

quoted

quoted

Odd.  If I copy and paste from Thunderbird, its fine.  But if I
save the body out as an attachment from mutt, it fails.

I wonder if it has to do with the From header appearing in the top
of the body; this header has to be escaped with a leading space in
mbox format.  It looks like Thunderbird might be doing some magic to
remove that leading space from the context lines, while mutt isn't.

FYI: the Thunderbird version included this header:
Content-Type:  text/plain; charset=ISO-8859-1; format=flowed

The format=flowed part shows that Thunderbird is reformatting
whitespace. You can disable that:
http://kb.mozillazine.org/Plain_text_e-mail_-_Thunderbird#Completely_plain_email

Thanks, this was indeed helpful. I was relying on the "Toggle Word
Wrap" extension [1] to handle this, but apparently it only changes how
the *sender* sees the message, but does not remove "format=flowed" if
word wrap is turned off. I've sent an according suggestion to the
extension's author.

[1] https://addons.mozilla.org/en-US/firefox/addon/2351

-- 
Sebastian Schuberth