[PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Philip Oakley]

This updates two patches in the series based on Eric Sunshine's comments.

Patch 8b updates the commit message to make clear what was going wrong.

Patch 10b improves the perl code.

Junio: would a full re-roll be appropriate at a suitable point?

Philip Oakley (2):

  engine.pl: ignore invalidcontinue.obj which is known to MSVC
  engine.pl: delete the captured stderr file if empty


-- 
2.4.2.windows.1.5.gd32afb6

[PATCH v2 8b/16] engine.pl: ignore invalidcontinue.obj which is known to MSVC

[Philip Oakley]

Commit 4b623d8 (MSVC: link in invalidcontinue.obj for better
POSIX compatibility, 2014-03-29) introduced invalidcontinue.obj
into the Makefile output, which was not parsed correctly by the
buildsystem. Ignore it, as it is known to Visual Studio and,
there is no matching source file.

Only substitute filenames ending with .o when generating the
source .c filename, otherwise a .cbj file may be expected.

Split the .o and .obj processing; 'make' does not produce .obj
files.

In the future there may be source files that produce .obj files
so keep the two issues (.obj files with & without source files)
separate.

Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
 contrib/buildsystems/engine.pl | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index 60c7a7d..9db3d43 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -289,7 +289,7 @@ sub handleLibLine
 #    exit(1);
     foreach (@objfiles) {
         my $sourcefile = $_;
-        $sourcefile =~ s/\.o/.c/;
+        $sourcefile =~ s/\.o$/.c/;
         push(@sources, $sourcefile);
         push(@cflags, @{$compile_options{"${sourcefile}_CFLAGS"}});
         push(@defines, @{$compile_options{"${sourcefile}_DEFINES"}});
@@ -333,8 +333,12 @@ sub handleLinkLine
         } elsif ($part =~ /\.(a|lib)$/) {
             $part =~ s/\.a$/.lib/;
             push(@libs, $part);
-        } elsif ($part =~ /\.(o|obj)$/) {
+        } elsif ($part eq 'invalidcontinue.obj') {
+            # ignore - known to MSVC
+        } elsif ($part =~ /\.o$/) {
             push(@objfiles, $part);
+        } elsif ($part =~ /\.obj$/) {
+            # do nothing, 'make' should not be producing .obj, only .o files
         } else {
             die "Unhandled link option @ line $lineno: $part";
         }
@@ -343,7 +347,7 @@ sub handleLinkLine
 #    exit(1);
     foreach (@objfiles) {
         my $sourcefile = $_;
-        $sourcefile =~ s/\.o/.c/;
+        $sourcefile =~ s/\.o$/.c/;
         push(@sources, $sourcefile);
         push(@cflags, @{$compile_options{"${sourcefile}_CFLAGS"}});
         push(@defines, @{$compile_options{"${sourcefile}_DEFINES"}});
-- 
2.3.1

[PATCH v2 10b/16] engine.pl: delete the captured stderr file if empty

[Philip Oakley]

Keep the build clean of extraneous files if it is indeed clean.
Otherwise leave the msvc-build-makedryerrors.txt file both as
a flag for any CI system or for manual debugging.

Alternatively, with improved syntactic sugar[1]:
	unlink $ErrsFile if -f -z $ErrsFile;
could be used but requires Perl 5.10 or later, which is not
available on Msysgit, but is available on the newer Git-for-Windows
SDK on Msys2 [2].

Note that the file will contain the new values of the GIT_VERSION
and GITGUI_VERSION if they were generated by the make file. They
are omitted if the release is tagged and identically defined in
their respective GIT_VERSION_GEN file DEF_VER variables.

[1]: http://perldoc.perl.org/functions/-X.html
[2]: http://git-for-windows.github.io/

Helped-by:  Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
Eric's help gmane.comp.version-control.msysgit/21745
---
 contrib/buildsystems/engine.pl | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/contrib/buildsystems/engine.pl b/contrib/buildsystems/engine.pl
index a6999b6..154575d 100755
--- a/contrib/buildsystems/engine.pl
+++ b/contrib/buildsystems/engine.pl
@@ -77,6 +77,8 @@ EOM
 
 my $ErrsFile = "msvc-build-makedryerrors.txt";
 @makedry = `cd $git_dir && make -n MSVC=1 V=1 2>$ErrsFile` if !@makedry;
+# test for an empty Errors file and remove it
+unlink $ErrsFile if -f $ErrsFile && -z _;
 
 # Parse the make output into usable info
 parseMakeOutput();
-- 
2.3.1

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Junio C Hamano]

Philip Oakley <philipoakley@iee.org> writes:

> This updates two patches in the series based on Eric Sunshine's comments.
>
> Patch 8b updates the commit message to make clear what was going wrong.
>
> Patch 10b improves the perl code.

Is v2b like saying v3 or something else?  Does 8b replaces 8 or
updates it (i.e. comes between 8 and 9)?

> Junio: would a full re-roll be appropriate at a suitable point?

Probably, but I'd like to see people try it out and give positive
feedback first.  This part of the tree I can give no input or pre-
pushout testing at all.

Who are the people involved in this part of the system in the past?
Does "shortlog -n --no-merges contrib/buildsystems compat/vcbuild"
tell us anything?


> Philip Oakley (2):
>
>   engine.pl: ignore invalidcontinue.obj which is known to MSVC
>   engine.pl: delete the captured stderr file if empty

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
> Philip Oakley <philipoakley@iee.org> writes:
>
>> This updates two patches in the series based on Eric Sunshine's
>> comments.
>>
>> Patch 8b updates the commit message to make clear what was going
>> wrong.
>>
>> Patch 10b improves the perl code.
>
> Is v2b like saying v3 or something else?  Does 8b replaces 8 or
> updates it (i.e. comes between 8 and 9)?


Sorry for the confusion. Yes these are quick replacements, rather than
re-rolling the whole series immediately.

>
>> Junio: would a full re-roll be appropriate at a suitable point?
>
> Probably, but I'd like to see people try it out and give positive
> feedback first.  This part of the tree I can give no input or pre-
> pushout testing at all.

It has been tried out on the Msysgit list, and also against the github
Pull Request, with responses noted there.

I'll do another branch / rebase and PR onto the G4W SDK as well,
for an extra chance at getting more replies. Ideally, if part of this
mainstream Git, it would get picked up automatically by them
(rather than being local 'fixes' endlessly carried forward).

>
> Who are the people involved in this part of the system in the past?
> Does "shortlog -n --no-merges contrib/buildsystems compat/vcbuild"
> tell us anything?
>

There has been no activity here on the 'create a visual studio project'
aspects in the last few years. Any changes listed in the logs relate to
ensuring that the MSVC compiler will run as part of a regular Makefile
run (IIUC). The last significant commit was 74cf9bd (engine.pl: Fix a
recent breakage of the buildsystem generator, 2010-01-22) Ramsay Jones,
so that's five and a half years. Mind you, it's taken me a while to find 
all
the bit rots.

>
>> Philip Oakley (2):
>

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Junio C Hamano]

"Philip Oakley" <philipoakley@iee.org> writes:

> ... Ideally, if part of this
> mainstream Git, it would get picked up automatically by them
> (rather than being local 'fixes' endlessly carried forward).

Actually, that is not "ideal", but what I want to avoid.

As I do not do Windows, it simply is wrong for me to apply changes
that are very likely to affect Windows folks without seeing their
support first, which they may end up having to revert on their end
and endlessly carry that revert forward.  That is why I very much
prefer to see changes get there first and then forwarded in my
direction once they are happy with them.

> There has been no activity here on the 'create a visual studio project'
> aspects in the last few years. Any changes listed in the logs relate to
> ensuring that the MSVC compiler will run as part of a regular Makefile
> run (IIUC). The last significant commit was 74cf9bd (engine.pl: Fix a
> recent breakage of the buildsystem generator, 2010-01-22) Ramsay Jones,
> so that's five and a half years.

I think Ramsay is still around on the list; I do not know if he
still does Windows, though.

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> ... Ideally, if part of this
>> mainstream Git, it would get picked up automatically by them
>> (rather than being local 'fixes' endlessly carried forward).
>
> Actually, that is not "ideal", but what I want to avoid.
>
> As I do not do Windows, it simply is wrong for me to apply changes
> that are very likely to affect Windows folks without seeing their
> support first,...

Just to clarify this part.  I do not do RedHat, Solaris or OSX,
either.  Also MSVC may not be what GfW folks primarily target.

But the thing is that (1) Windows is so much different, and (2) GfW
folks are much more qualified to judge platform-specific issues on
Windows than I am.

Even though I may still need to have a say in the overall structure
of the changes to the upstream tree coming from them (e.g. "Don't
sprinkle #ifdef all over the generic code; instead add a wrapper or
two in compat/ to keep the generic code generic" is something I may
tell them when rejecting a change forwarded to me), I trust them a
lot more than I trust myself when it comes to what the changes do in
the platform-specific part and how they do it.

Thanks.

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Philip Oakley]

From: "Junio C Hamano" <gitster@pobox.com>
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "Philip Oakley" <philipoakley@iee.org> writes:
>>
>>> ... Ideally, if part of this
>>> mainstream Git, it would get picked up automatically by them
>>> (rather than being local 'fixes' endlessly carried forward).
>>
>> Actually, that is not "ideal", but what I want to avoid.
>>
>> As I do not do Windows, it simply is wrong for me to apply changes
>> that are very likely to affect Windows folks without seeing their
>> support first,...
>
> Just to clarify this part.  I do not do RedHat, Solaris or OSX,
> either.  Also MSVC may not be what GfW folks primarily target.
>
> But the thing is that (1) Windows is so much different, and (2) GfW
> folks are much more qualified to judge platform-specific issues on
> Windows than I am.
>
> Even though I may still need to have a say in the overall structure
> of the changes to the upstream tree coming from them (e.g. "Don't
> sprinkle #ifdef all over the generic code; instead add a wrapper or
> two in compat/ to keep the generic code generic" is something I may
> tell them when rejecting a change forwarded to me), I trust them a
> lot more than I trust myself when it comes to what the changes do in
> the platform-specific part and how they do it.
>
> Thanks.
> --
Thanks for the extra clarification. I'll ask if they can confirm this 
update on GfW.

I've also asked Ramsay what his current situation is re- you previous 
email and the msvc-build.

regards

Philip 

Re: [PATCH v2b 00/16, 2 updates] Make the msvc-build scripts work again

[Ramsay Jones]

On 21/07/15 20:25, Junio C Hamano wrote:
> "Philip Oakley" <philipoakley@iee.org> writes:
> 
>> ... Ideally, if part of this
>> mainstream Git, it would get picked up automatically by them
>> (rather than being local 'fixes' endlessly carried forward).
> 
> Actually, that is not "ideal", but what I want to avoid.
> 
> As I do not do Windows, it simply is wrong for me to apply changes
> that are very likely to affect Windows folks without seeing their
> support first, which they may end up having to revert on their end
> and endlessly carry that revert forward.  That is why I very much
> prefer to see changes get there first and then forwarded in my
> direction once they are happy with them.
> 
>> There has been no activity here on the 'create a visual studio project'
>> aspects in the last few years. Any changes listed in the logs relate to
>> ensuring that the MSVC compiler will run as part of a regular Makefile
>> run (IIUC). The last significant commit was 74cf9bd (engine.pl: Fix a
>> recent breakage of the buildsystem generator, 2010-01-22) Ramsay Jones,
>> so that's five and a half years.
> 
> I think Ramsay is still around on the list; I do not know if he
> still does Windows, though.

[Sorry for not noticing this sooner, but I'm currently moving home
(among other things) and, as a result, I have not been able to
devote much time to the list ... (or anything else ;-) ]

I don't do much with MinGW or MSVC these days (I do still try to
keep cygwin running - it's currently not in good shape). My MSVC
installation is somewhat old (2008 I believe) and confined to my
old 32-bit laptop (which doesn't get booted up too often now).

I had a quick squint at the patches and, at first glance, they
looked quite reasonable to me, but I have not tested them. I can't
promise to test them anytime soon (and my MSVC may be too old for
these patches?). Sorry! :(

[If I find some time soon, I will give them a try and let you know.]

ATB,
Ramsay Jones