threads / patch / 21060

patch, 2 partsRe: [PATCH 1/2] Make generated MSVC solution file open from Windows Explorer

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

## tl;dr

16 messages between Sep 24, 2009 and Sep 28, 2009. Diffs are folded; open one to read it.

replies: 15people: 5as markdown or json

Sebastian Schuberth· Sep 24, 2009, 14:40 UTC · lore

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

 From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
From: Sebastian Schuberth <sschuberth@gmail.com>
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 <sschuberth@gmail.com>
---
  contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
  1 files changed, 4 insertions(+), 1 deletions(-)
Show changes to contrib/buildsystems/Generators/Vcproj.pm +4 −1
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
Shawn O. Pearce· Sep 25, 2009, 22:05 UTC · re: Sebastian Schuberth · lore
Sebastian Schuberth <sschuberth@gmail.com> wrote:
Show 12 quoted lines
> From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
> From: Sebastian Schuberth <sschuberth@gmail.com>
> 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.
Alex Riesen· Sep 25, 2009, 22:11 UTC · re: Shawn O. Pearce · lore
On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 12 quoted lines
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> 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'

Sebastian Schuberth· Sep 25, 2009, 22:45 UTC · re: Alex Riesen · lore
On Sat, Sep 26, 2009 at 00:11, Alex Riesen <raa.lkml@gmail.com> wrote:
Show 16 quoted lines
> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>>> 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· Sep 25, 2009, 22:41 UTC · re: Shawn O. Pearce · lore
On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 17 quoted lines
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> From c6d29a2d243647bb2877eb2114938ae20c8e56e5 Mon Sep 17 00:00:00 2001
>> From: Sebastian Schuberth <sschuberth@gmail.com>
>> 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
Shawn O. Pearce· Sep 25, 2009, 22:59 UTC · re: Sebastian Schuberth · lore
Sebastian Schuberth <sschuberth@gmail.com> wrote:
Show 6 quoted lines
> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> > 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?
Show 5 quoted 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.

-- 
Shawn.
Sebastian Schuberth· Sep 25, 2009, 23:58 UTC · re: Shawn O. Pearce · lore
On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 10 quoted lines
> Sebastian Schuberth <sschuberth@gmail.com> wrote:
>> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > 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
Shawn O. Pearce· Sep 26, 2009, 00:05 UTC · re: Sebastian Schuberth · lore
Sebastian Schuberth <sschuberth@gmail.com> wrote:
Show 14 quoted lines
> On Sat, Sep 26, 2009 at 00:59, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Sebastian Schuberth <sschuberth@gmail.com> wrote:
> >> On Sat, Sep 26, 2009 at 00:05, Shawn O. Pearce <spearce@spearce.org> wrote:
> >> > 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.
Sebastian Schuberth· Sep 26, 2009, 09:45 UTC · re: Shawn O. Pearce · lore
On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 9 quoted 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.
>
> 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
Shawn O. Pearce· Sep 26, 2009, 20:05 UTC · re: Sebastian Schuberth · lore
Sebastian Schuberth <sschuberth@gmail.com> wrote:
Show 13 quoted lines
> On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce <spearce@spearce.org> 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?
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.
Baz· Sep 28, 2009, 10:36 UTC · re: Sebastian Schuberth · lore
2009/9/26 Sebastian Schuberth <sschuberth@gmail.com>:
Show 9 quoted lines
> On Sat, Sep 26, 2009 at 02:05, Shawn O. Pearce <spearce@spearce.org> 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.
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

Show 16 quoted 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Sebastian Schuberth· Sep 28, 2009, 13:40 UTC · re: Baz · lore
On Mon, Sep 28, 2009 at 12:36, Baz <brian.ewins@gmail.com> wrote:
Show 14 quoted 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

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
Marius Storm-Olsen· Sep 28, 2009, 11:34 UTC · re: Sebastian Schuberth · lore

[PATCH 0/2] MSVC generator fixups

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(-)
Marius Storm-Olsen· Sep 28, 2009, 11:34 UTC · re: Marius Storm-Olsen · lore

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

From: Sebastian Schuberth <sschuberth@gmail.com>

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 <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
 contrib/buildsystems/Generators/Vcproj.pm |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)
Show changes to contrib/buildsystems/Generators/Vcproj.pm +4 −1
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
Marius Storm-Olsen· Sep 28, 2009, 11:34 UTC · re: Marius Storm-Olsen · lore

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

From: Sebastian Schuberth <sschuberth@gmail.com>

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 <sschuberth@gmail.com>
Acked-by: Marius Storm-Olsen <mstormo@gmail.com>
---
 contrib/buildsystems/Generators/Vcproj.pm |   42 +++++++---------------------
 1 files changed, 11 insertions(+), 31 deletions(-)
Show changes to contrib/buildsystems/Generators/Vcproj.pm +11 −31
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

← back to recent threads