Make generated MSVC solution file open from Windows Explorer

PATCH In review Sebastian Schuberth 5 participants 16 messages Jun 15, 2016 – Aug 13, 2016

Share & tools

Sebastian Schuberth

author

2016-08-13 23:24 UTC #0 lore raw

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

From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <[email protected]>
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 <[email protected]>

---
 contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

contrib/buildsystems/Generators/Vcproj.pm +4 -1

index 00ec0c1..50daa03 100644
@@ -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 = $_;

Signature · 1 line

1.6.4.msysgit.0

Shawn O. Pearce

2016-06-15 22:47 UTC #1 lore raw

Quoted 5 lines · Sebastian Schuberth

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

Quoted 7 lines

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.

Signature · 1 line

Shawn.

Alex Riesen

2016-06-15 22:47 UTC #2 lore raw

Quoted 9 lines · Shawn O. Pearce

Quoted 7 lines · Sebastian Schuberth
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.

Quoted 3 lines

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'

Sebastian Schuberth

author

2016-06-15 22:47 UTC #3 lore raw

Quoted 10 lines · Alex Riesen

Quoted 9 lines · Shawn O. Pearce
Quoted 7 lines · Sebastian Schuberth
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.

Quoted 6 lines

Quoted 3 lines
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.

Signature · 1 line

Sebastian Schuberth

Sebastian Schuberth

author

2016-06-15 22:47 UTC #4 lore raw

In reply to Shawn O. Pearce

Quoted 14 lines · Shawn O. Pearce

Quoted 5 lines · Sebastian Schuberth
From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <[email protected]>
Date: Thu, 24 Sep 2009 15:52:25 +0200
Subject: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer
Quoted 7 lines
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.

Quoted 3 lines

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?

Signature · 1 line

Sebastian Schuberth

Shawn O. Pearce

2016-06-15 22:47 UTC #5 lore raw

Quoted 6 lines · Sebastian Schuberth

Quoted 3 lines · Shawn O. Pearce
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?

Quoted 5 lines

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.

Signature · 1 line

Shawn.

Sebastian Schuberth

author

2016-06-15 22:47 UTC #6 lore raw

Quoted 10 lines · Shawn O. Pearce

Quoted 6 lines · Sebastian Schuberth
Quoted 3 lines · Shawn O. Pearce
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.

Signature · 1 line

Sebastian Schuberth

Shawn O. Pearce

2016-06-15 22:47 UTC #7 lore raw

Quoted 7 lines · Sebastian Schuberth

Quoted 6 lines · Shawn O. Pearce
Quoted 4 lines · Sebastian Schuberth
Quoted 1 line · Shawn O. Pearce
Something is wrong with both patches; neither applies.
Hmm, the patches apply fine onto master for me.

Quoted 7 lines

Quoted 2 lines
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?

Signature · 1 line

Shawn.

Sebastian Schuberth

author

2016-06-15 22:47 UTC #8 lore raw

Quoted 9 lines · Shawn O. Pearce

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?

Signature · 1 line

Sebastian Schuberth

Shawn O. Pearce

2016-06-15 22:47 UTC #9 lore raw

Quoted 9 lines · Sebastian Schuberth

Quoted 8 lines · Shawn O. Pearce
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.

Quoted 4 lines

Quoted 1 line
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.

Quoted 2 lines

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.

Signature · 1 line

Shawn.

Baz

2016-06-15 22:47 UTC #10 lore raw

In reply to Sebastian Schuberth

2009/9/26 Sebastian Schuberth <[email protected]>:

Quoted 9 lines · Shawn O. Pearce

Quoted 8 lines
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 16 lines

Quoted 2 lines
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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Sebastian Schuberth

author

2016-06-15 22:47 UTC #11 lore raw

Quoted 8 lines · Baz

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

Quoted 6 lines

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

Signature · 1 line

Sebastian Schuberth

Marius Storm-Olsen

2016-06-15 22:47 UTC #12 lore raw

cover MSVC generator fixups

In reply to Sebastian Schuberth

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

Sebastian Schuberth

author

2016-06-15 22:47 UTC #13 lore raw

Re: [PATCH 0/2] MSVC generator fixups

Quoted 3 lines

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!

Signature · 1 line

Sebastian Schuberth

Marius Storm-Olsen

2016-06-15 22:47 UTC #14 lore raw

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

In reply to Marius Storm-Olsen

From: Sebastian Schuberth <[email protected]>

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 <[email protected]>

Acked-by Marius Storm-Olsen <[email protected]>

---
 contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

contrib/buildsystems/Generators/Vcproj.pm +4 -1

index 00ec0c1..50daa03 100644
@@ -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 = $_;

Signature · 1 line

1.6.5.rc2.177.ga9dd6

Marius Storm-Olsen

2016-06-15 22:47 UTC #15 lore raw

PATCH 2/2 Make just opening the generated MSVC solution file not modify it

In reply to Marius Storm-Olsen

From: Sebastian Schuberth <[email protected]>

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 <[email protected]>

Acked-by Marius Storm-Olsen <[email protected]>

---
 contrib/buildsystems/Generators/Vcproj.pm |   42 +++++++---------------------
 1 files changed, 11 insertions(+), 31 deletions(-)

contrib/buildsystems/Generators/Vcproj.pm +11 ~~-31~~

index 50daa03..d53ff2c 100644
@@ -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;

Signature · 1 line

1.6.5.rc2.177.ga9dd6