FeatureRequest: Build improvements for Windows

FeatureRequest: Build improvements for Windows

[Dangling Pointer]

Hello,
 
In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post.
 
With VS 2015, C99 support is "finally" added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP. 
 
If all the instances of fallback code guarded by "#ifdef _MSC_VER" and "#if defined(_MSC_VER) && _MSC_VER < xxx" etc. are removed from git's source code in favor of VS2015, it will help the code maintainability in future and standard C code will thrive. The very few enthusiasts who were building Windows code can download the said free edition of VS2015 and build the project the same way as they were building before (I.e. using CLI .
 
Update to docs will look like: "To build on Windows, you need to use MinGW or VS2015 (community, express desktop, professional or enterprise editions)". I think this is choice for those few, who were building from source. Also, Clang and LLVM are also now available on Windows. So many options if someone is looking hard. What I am trying to say is dropping some century old version of VS support for a lazy user should not be an excuse for a deal-breaker anymore. World is moving at much faster pace to care about lazy. :)
 
In addition to Jenkins, there is also a free-for-OSS and easy-to-configure CI service called AppVeyor, which let you build using VS2015 and MInGW machineries (http://www.appveyor.com/updates/2015/07/21) and saves the artifacts for download or upload to somewhere. If git repo is configured with AppVeyor, it will automate the process of building releases for Windows, and there will be no version disparity like present (the current released version of git on Mac is v2.4.3 while that on misfortunate Windows is v1.9.5). 
 
In future if CMake (http://www.cmake.org/) is used in this repo to automate and unify all build systems, that is also available on AppVeyor, Jenkins, Travis etc.
 
Thank you for the patience and I hope someone will consider and approve these changes at some near point in future.
  		 	   		  

Re: FeatureRequest: Build improvements for Windows

[Jacob Keller]

On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer
<danglingpointer@outlook.com> wrote:
> Hello,
>
> In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post.
>
> With VS 2015, C99 support is "finally" added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP.
>

I think the big issue is whether it has support for the various unix
interfaces and unix shell commands we use. MinGW/MSYS comes with
support for the unix interface, which I don't believe is that actually
supported via MSYS and I don't know if VS2015 is supported? I don't
think it's due to the C99 but due to need of posix interface which is
not normally (fully) provided by Windows.

Regards,
Jake

FW: FeatureRequest: Build improvements for Windows

[Dangling Pointer]

Hmm, it is already happening, isn't it? There is already a support of MSVCR in git's code base. I am referring to replacing that current support of 'older' MSVCR in favor of the latest one, so to make the git's code base comparatively coherent and organized (as some/many instances of #ifdef _MSC_VER and #if define (_MSC_VER) && _MSC_VER < xxx etc. will be gone, for instance we don't need fallback for sprint or snprintf since C99 std support for those is provisioned).



> ----------------------------------------
>> From: jacob.keller@gmail.com
>> Date: Sun, 26 Jul 2015 00:15:10 -0700
>> Subject: Re: FeatureRequest: Build improvements for Windows
>> To: danglingpointer@outlook.com
>> CC: git@vger.kernel.org
>>
>> On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer
>> <danglingpointer@outlook.com> wrote:
>>> Hello,
>>>
>>> In my understanding, the ratio between the mere consumers of git on Windows vs. people who compile git for Windows is 100,000 : 1. If there is a breaking change in the workflow of the latter set, who use Visual Studio to build git from source, I assume that is doable given a good reason, hence this post.
>>>
>>> With VS 2015, C99 support is "finally" added with some C11 features as well. See this blog: http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. One of the edition of new VS is Community edition, which is like professional edition but is free (also much superior than Express edition) and meant for open source projects. VS2015 also has the ability to target compiler for Wind-XP.
>>>
>>
>> I think the big issue is whether it has support for the various unix
>> interfaces and unix shell commands we use. MinGW/MSYS comes with
>> support for the unix interface, which I don't believe is that actually
>> supported via MSYS and I don't know if VS2015 is supported? I don't
>> think it's due to the C99 but due to need of posix interface which is
>> not normally (fully) provided by Windows.
>>
>> Regards,
>> Jake 		 	   		  

Re: FeatureRequest: Build improvements for Windows

[Philip Oakley]

(In-line posting preferred; top-posting deprecated ;-)
(retain all cc's)

> Hmm, it is already happening, isn't it? There is already a support of 
> MSVCR in git's code base. I am referring to replacing that current 
> support of 'older' MSVCR in favor of the latest one, so to make the 
> git's code base comparatively coherent and organized (as some/many 
> instances of #ifdef _MSC_VER and #if define (_MSC_VER) && _MSC_VER < 
> xxx etc. will be gone, for instance we don't need fallback for sprint 
> or snprintf since C99 std support for those is provisioned).
>

It's not clear if you (DP) are asking about using being able to use the 
Visual Studio IDE and gui to help visualise and develop the code, or to 
simply use the underlying MS compiler when making (using the Makefile) 
the Git code base.

One can compile the codebase using the MS compiler (given a suitable 
environment, and setting the right Makefile flags), but that may not be 
what you were thinking of.

The Windows team recently decided that the older Msysgit approach should 
be retired (can't find the link just now)  and a new approach based on 
Msys2 started (http://git-for-windows.github.io/ and 
https://github.com/git-for-windows/git/wiki/FAQ). This is nearing 
completion.

Meanwhile I have been working on fixing the msvc-build script, which can 
produce a git.sln and associated files (targeted originally at VS2008), 
and is now at the 'Validate this with the Windows guys' stage 
(http://marc.info/?l=git&m=143750907804881&w=2 et.seq.).

My code, for the new G4W SDK, has been rebased from the msygit version, 
and is now at https://github.com/git-for-windows/git/pull/256

Does that help for creating an IDE compilable version?

Also, many thanks for yournote about the new VS Community edition (I'm 
still mainly working on an XP notebook for ease of carry).

As an open community of independently minded folks it can tae a time to 
gel around a reasonably common approach, especially as Git will always 
be primarily focussed on Linux (it **is** the Linux (Linus's) VCS!).

>
>>> From: jacob.keller@gmail.com
>>> On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer
>>> <danglingpointer@outlook.com> wrote:
>>>> Hello,
>>>>
>>>> In my understanding, the ratio between the mere consumers of git on 
>>>> Windows vs. people who compile git for Windows is 100,000 : 1. If 
>>>> there is a breaking change in the workflow of the latter set, who 
>>>> use Visual Studio to build git from source, I assume that is doable 
>>>> given a good reason, hence this post.
>>>>
>>>> With VS 2015, C99 support is "finally" added with some C11 features 
>>>> as well. See this blog: 
>>>> http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx. 
>>>> One of the edition of new VS is Community edition, which is like 
>>>> professional edition but is free (also much superior than Express 
>>>> edition) and meant for open source projects. VS2015 also has the 
>>>> ability to target compiler for Wind-XP.
>>>>
>>>
>>> I think the big issue is whether it has support for the various unix
>>> interfaces and unix shell commands we use. MinGW/MSYS comes with
>>> support for the unix interface, which I don't believe is that 
>>> actually
>>> supported via MSYS and I don't know if VS2015 is supported? I don't
>>> think it's due to the C99 but due to need of posix interface which 
>>> is
>>> not normally (fully) provided by Windows.

Git's code retains a C89 compatibility (IIUC).

>>>
>>> Regards,
>>> Jake      --
--
Philip 

RE: FeatureRequest: Build improvements for Windows

[Dangling Pointer]

I searched in code and found instances of #ifdef _MSC_VER in https://github.com/git/git (original repository, not the fork).

I am coming from github, where I have found many native lib repositories have two build files, build.sh and build.cmd with

some windows-specific code turds like #ifdef _MSC_VER etc. which nobody appreciate because CL.exe up until last VS release

wasn't C99 complaint. This has changed with VS2015.


If git/git does not share this philosophy of having a build file for both nix and win, then I wonder why do we even have MS compiler

directives in git codebase in first place? That was the main source of confusion.


If the repo owner is willing to drop the old compiler support for Windows, since many windows users do not build from source

and tend to download the compiled binaries anyway.  If they want, they can always use MinGW and VS2015 to build. 


The idea is to keep the codebase clean from outdated _MSC_VER conditions. In this age,

free CI service (like AppVeyor) will build your code with latest compiler (MinGW GCC and MSVCR 2015) in a matter of minutes

and then make the release artifacts available for download. I really don't see any point in still using 8 years old compiler on a 15

years old OS when we can just throw a .yml (appveyor config) file in the repo root and let the cloud handle the build business and

verify the build by running tests. (well we are still using mailing lists, aren't we ;-)


Besides, I had no idea about this fork: https://github.com/msysgit/git but it seems to be falling behind significantly from the

upstream master (git/git).



----------------------------------------
> From: philipoakley@iee.org
> To: danglingpointer@outlook.com
> CC: jacob.keller@gmail.com; git@vger.kernel.org
> Subject: Re: FeatureRequest: Build improvements for Windows
> Date: Sun, 26 Jul 2015 12:27:19 +0100
>
> (In-line posting preferred; top-posting deprecated ;-)
> (retain all cc's)
>
>> Hmm, it is already happening, isn't it? There is already a support of
>> MSVCR in git's code base. I am referring to replacing that current
>> support of 'older' MSVCR in favor of the latest one, so to make the
>> git's code base comparatively coherent and organized (as some/many
>> instances of #ifdef _MSC_VER and #if define (_MSC_VER) && _MSC_VER <
>> xxx etc. will be gone, for instance we don't need fallback for sprint
>> or snprintf since C99 std support for those is provisioned).
>>
>
> It's not clear if you (DP) are asking about using being able to use the
> Visual Studio IDE and gui to help visualise and develop the code, or to
> simply use the underlying MS compiler when making (using the Makefile)
> the Git code base.
>
> One can compile the codebase using the MS compiler (given a suitable
> environment, and setting the right Makefile flags), but that may not be
> what you were thinking of.
>
> The Windows team recently decided that the older Msysgit approach should
> be retired (can't find the link just now) and a new approach based on
> Msys2 started (http://git-for-windows.github.io/ and
> https://github.com/git-for-windows/git/wiki/FAQ). This is nearing
> completion.
>
> Meanwhile I have been working on fixing the msvc-build script, which can
> produce a git.sln and associated files (targeted originally at VS2008),
> and is now at the 'Validate this with the Windows guys' stage
> (http://marc.info/?l=git&m=143750907804881&w=2 et.seq.).
>
> My code, for the new G4W SDK, has been rebased from the msygit version,
> and is now at https://github.com/git-for-windows/git/pull/256
>
> Does that help for creating an IDE compilable version?
>
> Also, many thanks for yournote about the new VS Community edition (I'm
> still mainly working on an XP notebook for ease of carry).
>
> As an open community of independently minded folks it can tae a time to
> gel around a reasonably common approach, especially as Git will always
> be primarily focussed on Linux (it **is** the Linux (Linus's) VCS!).
>
>>
>>>> From: jacob.keller@gmail.com
>>>> On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer
>>>> <danglingpointer@outlook.com> wrote:
>>>>> Hello,
>>>>>
>>>>> In my understanding, the ratio between the mere consumers of git on
>>>>> Windows vs. people who compile git for Windows is 100,000 : 1. If
>>>>> there is a breaking change in the workflow of the latter set, who
>>>>> use Visual Studio to build git from source, I assume that is doable
>>>>> given a good reason, hence this post.
>>>>>
>>>>> With VS 2015, C99 support is "finally" added with some C11 features
>>>>> as well. See this blog:
>>>>> http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx.
>>>>> One of the edition of new VS is Community edition, which is like
>>>>> professional edition but is free (also much superior than Express
>>>>> edition) and meant for open source projects. VS2015 also has the
>>>>> ability to target compiler for Wind-XP.
>>>>>
>>>>
>>>> I think the big issue is whether it has support for the various unix
>>>> interfaces and unix shell commands we use. MinGW/MSYS comes with
>>>> support for the unix interface, which I don't believe is that
>>>> actually
>>>> supported via MSYS and I don't know if VS2015 is supported? I don't
>>>> think it's due to the C99 but due to need of posix interface which
>>>> is
>>>> not normally (fully) provided by Windows.
>
> Git's code retains a C89 compatibility (IIUC).
>
>>>>
>>>> Regards,
>>>> Jake --
> --
> Philip
>
> --
> 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 		 	   		  

Re: FeatureRequest: Build improvements for Windows

[Philip Oakley]

Hi,
From: "Dangling Pointer" <danglingpointer@outlook.com>
>I searched in code and found instances of #ifdef _MSC_VER in
>https://github.com/git/git (original repository, not the fork).
>
> I am coming from github, where I have found many native lib
> repositories have two build files, build.sh and build.cmd with

Git is a *nix code base so rather than using build.*, it obviously uses 
a Makefile. The makefile can be slightly convoluted because it seeks to 
have maximum backward compatibility.

> some windows-specific code turds like #ifdef _MSC_VER etc. which
> nobody appreciate because CL.exe up until last VS release
>
> wasn't C99 complaint. This has changed with VS2015.
https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L174
The C89 compatibility came up recently (2015-04-30). It's still a live 
issue.
>
>
> If git/git does not share this philosophy of having a build file for
> both nix and win, then I wonder why do we even have MS compiler

The git/git philosophy is maximum backward compatibility, with Gnu/Linux 
as
a given.

> directives in git codebase in first place? That was the main source of
> confusion.
>
> If the repo owner is willing to drop the old compiler support for
> Windows, since many windows users do not build from source
Surely it's a case of building on the shoulders of former giants. Many
are still using VS200* out in the real world (my work uses V2008 and 
VS2006 commonly because of the need to support older embedded equipment)

> and tend to download the compiled binaries anyway.  If they want, they
> can always use MinGW and VS2015 to build.

The G4W projects do provide binaries as well as source code, and support
older compilers... It's the choice here.
>
>
> The idea is to keep the codebase clean from outdated _MSC_VER
> conditions. In this age,
> free CI service (like AppVeyor) will build your code with latest
> compiler (MinGW GCC and MSVCR 2015) in a matter of minutes
> and then make the release artifacts available for download. I really
> don't see any point in still using 8 years old compiler on a 15
> years old OS
 That's only a third of my coding life ;-). It's nice to use the latest
and greatest, but sometimes "if it ain't broke, don't fix it" applies to
choosing what to spend one's free hours on.

> when we can just throw a .yml (appveyor config) file in the repo root
> and let the cloud handle the build business and
> verify the build by running tests. (well we are still using mailing
> lists, aren't we ;-)
>
>
> Besides, I had no idea about this fork: https://github.com/msysgit/git
> but it seems to be falling behind significantly from the
>
> upstream master (git/git).

If you look at the home page of the
https://github.com/git-for-windows/git/wiki/ I provided, you'll be able
to see why/how the team decided to leave that fork behind (though it did
get a major security fix applied). Folks on the *nix side can be using
v1.7.x and still have it all work, so there is no shame in using the
msysgit1.9.5.

The main point being that Git seeks to maintain backward compatibility
and is careful about how code is introduced.

It can be frustrating when one's latest and greatest idea is not as
readily picked up as hoped, but a moment (or two's) reflection will help
understand the broader issues that may pertain. That said useful new
fetures (with justification, code, documentation, and review ;-) are
welcome.

Do have a look at the
https://github.com/git-for-windows/git/wiki/How-to-participate

>
> ----------------------------------------
>> From: philipoakley@iee.org
>> (In-line posting preferred; top-posting deprecated ;-)
>> (retain all cc's)
>>
>>> Hmm, it is already happening, isn't it? There is already a support
>>> of
>>> MSVCR in git's code base. I am referring to replacing that current
>>> support of 'older' MSVCR in favor of the latest one, so to make the
>>> git's code base comparatively coherent and organized (as some/many
>>> instances of #ifdef _MSC_VER and #if define (_MSC_VER) && _MSC_VER <
>>> xxx etc. will be gone, for instance we don't need fallback for
>>> sprint
>>> or snprintf since C99 std support for those is provisioned).
>>>
>>
>> It's not clear if you (DP) are asking about using being able to use
>> the
>> Visual Studio IDE and gui to help visualise and develop the code, or
>> to
>> simply use the underlying MS compiler when making (using the
>> Makefile)
>> the Git code base.
>>
>> One can compile the codebase using the MS compiler (given a suitable
>> environment, and setting the right Makefile flags), but that may not
>> be
>> what you were thinking of.
>>
>> The Windows team recently decided that the older Msysgit approach
>> should
>> be retired (can't find the link just now) and a new approach based on
>> Msys2 started (http://git-for-windows.github.io/ and
>> https://github.com/git-for-windows/git/wiki/FAQ). This is nearing
>> completion.
>>
>> Meanwhile I have been working on fixing the msvc-build script, which
>> can
>> produce a git.sln and associated files (targeted originally at
>> VS2008),
>> and is now at the 'Validate this with the Windows guys' stage
>> (http://marc.info/?l=git&m=143750907804881&w=2 et.seq.).
>>
>> My code, for the new G4W SDK, has been rebased from the msygit
>> version,
>> and is now at https://github.com/git-for-windows/git/pull/256
>>
>> Does that help for creating an IDE compilable version?
>>
>> Also, many thanks for yournote about the new VS Community edition
>> (I'm
>> still mainly working on an XP notebook for ease of carry).
>>
>> As an open community of independently minded folks it can tae a time
>> to
>> gel around a reasonably common approach, especially as Git will
>> always
>> be primarily focussed on Linux (it **is** the Linux (Linus's) VCS!).
>>
>>>
>>>>> From: jacob.keller@gmail.com
>>>>> On Sat, Jul 25, 2015 at 11:23 PM, Dangling Pointer
>>>>> <danglingpointer@outlook.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> In my understanding, the ratio between the mere consumers of git
>>>>>> on
>>>>>> Windows vs. people who compile git for Windows is 100,000 : 1. If
>>>>>> there is a breaking change in the workflow of the latter set, who
>>>>>> use Visual Studio to build git from source, I assume that is
>>>>>> doable
>>>>>> given a good reason, hence this post.
>>>>>>
>>>>>> With VS 2015, C99 support is "finally" added with some C11
>>>>>> features
>>>>>> as well. See this blog:
>>>>>> http://blogs.msdn.com/b/vcblog/archive/2015/06/19/c-11-14-17-features-in-vs-2015-rtm.aspx.
>>>>>> One of the edition of new VS is Community edition, which is like
>>>>>> professional edition but is free (also much superior than Express
>>>>>> edition) and meant for open source projects. VS2015 also has the
>>>>>> ability to target compiler for Wind-XP.
>>>>>>
>>>>>
>>>>> I think the big issue is whether it has support for the various
>>>>> unix
>>>>> interfaces and unix shell commands we use. MinGW/MSYS comes with
>>>>> support for the unix interface, which I don't believe is that
>>>>> actually
>>>>> supported via MSYS and I don't know if VS2015 is supported? I
>>>>> don't
>>>>> think it's due to the C99 but due to need of posix interface which
>>>>> is
>>>>> not normally (fully) provided by Windows.
>>
>> Git's code retains a C89 compatibility (IIUC).
>>
>>>>>
>>>>> Regards,
>>>>> Jake --
>> --
>> Philip