From the documentation of said setting:
This boolean will enable fsync() when writing object files.
This is a total waste of time and effort on a filesystem that
orders data writes properly, but can be useful for filesystems
that do not use journalling (traditional UNIX filesystems) or
that only journal metadata and not file contents (OS X’s HFS+,
or Linux ext3 with "data=writeback").
The most common file system on Windows (NTFS) does not guarantee that
order, therefore a sudden loss of power (or any other event causing an
unclean shutdown) would cause corrupt files (i.e. files filled with
NULs). Therefore we need to change the default.
Note that the documentation makes it sound as if this causes really bad
performance. In reality, writing loose objects is something that is done
only rarely, and only a handful of files at a time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
From the documentation of said setting:
This boolean will enable fsync() when writing object files.
This is a total waste of time and effort on a filesystem that
orders data writes properly, but can be useful for filesystems
that do not use journalling (traditional UNIX filesystems) or
that only journal metadata and not file contents (OS X’s HFS+,
or Linux ext3 with "data=writeback").
The most common file system on Windows (NTFS) does not guarantee that
order, therefore a sudden loss of power (or any other event causing an
unclean shutdown) would cause corrupt files (i.e. files filled with
NULs). Therefore we need to change the default.
Note that the documentation makes it sound as if this causes really bad
performance. In reality, writing loose objects is something that is done
only rarely, and only a handful of files at a time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We ran out GUIDs. Again. But there is no need to: we can generate them
semi-randomly from the target file name of the project.
Note: the Vcproj generator is probably only interesting for historical
reasons; nevertheless, the Vcxproj generator in the Git for Windows
project is based on the Vcproj generator and it is better to backport
the fix than to let Vcproj have the hard-coded list of GUIDs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We ran out GUIDs. Again. But there is no need to: we can generate them
semi-randomly from the target file name of the project.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The problem with not having, say, git-receive-pack.exe after a full
build is that the test suite will then happily use the *installed*
git-receive-pack.exe because it finds nothing else.
Absolutely not what we want. We want to have confidence that our test
covers the MSVC-built Git executables, and not some random stuff.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of the `vcxproj` target is to generate .sln/.vcxproj files and
then commit them, to be used elsewhere. Typically, this is done in a
VSTS job whenever `master` changes. So there is little use in
initializing vcpkg and building all the dependencies: they are not
necessary here.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `vcxproj` target does not, in fact, depend on MSVC being defined, so
let's just move it outside of that block.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We just introduced a way to build Git for Windows with MSVC on the
command line using vcpkg-generated, up-to-date dependencies. Let's bring
that convenience to the Visual Studio project, too.
(The previous method, fetching NuGet packages, is fraught with problems:
as C++ libraries have to be built for every architecture and for every
toolset, the NuGet packages which we would like to consume fell behind
and are not up-to-date with the current versions of the libraries, e.g.
cURL and OpenSSL. By using vcpkg we avoid that problem, always building
the newest dependency versions.)
The trick is to initialize the VCPKG system once, and then build Git's
dependencies using it. We do that by attaching a pre-build event to the
libgit project (which is now the base project on which all others
depend, therefore no other project is built in paralleli, side-stepping
issues with vcpkg being unprepared for being run in parallel).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The .vcxproj's text nodes do not actually need to URL-encode double
quotes. So let's not do that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It really does depend on libgit. It does not hurt to let it depend on
xdiff, and it makes the code simpler.
It is necessary to get this dependency chain right, because we will
introduce a change where the vcpkg system is initialized before building
libgit. The vcpkg system will then build the dependencies needed by Git
(and thereby make the include headers available):
As the vcpkg system cannot be run in parallel (it does not lock,
wreaking havoc with files being accessed and written at the same time,
letting the vcpkg processes stumble over each others' toes. We prevent
that by ensuring that only one project is built at first: libgit. And
this project's PreBuildEvent will be used to initialize vcpkg and build
all dependencies. Subsequently, the other projects can be built in
parallel.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add .LIBs for zlib and openssl to <AdditionalDependencies>
to help linker when building with VS2017.
This closes https://github.com/git-for-windows/git/issues/1234
Note: this patch still leaves a couple of TODOs:
- It should be possible to add GEN.DEPS\lib to
<AdditionalLibraryDependencies> and then just set
<AdditionalDependencies> to the library basenames.
- Likewise, you should be able to copy GEN.DEPS\bin\*.dll
to the destination directory rather than using the full
paths in the $afterTargets lines.
(This is in line with items in <AdditionalIncludeDirectories>
referencing GEN.DEPS\include.)
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Toolset v120 corresponds to Visual Studio 2013. We already used
dependencies that were hardcoded to v140 (i.e. Visual Studio 2015), so
let's just remove the cruft.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Dependencies such as cURL and OpenSSL are necessary to build and run
Git. Previously, we obtained those dependencies by fetching NuGet
packages.
However, it is notoriously hard to keep NuGet packages of C/C++
libraries up-to-date, as the toolsets for different Visual Studio
versions are different, and the NuGet packages would have to ship them
all.
That is the reason why the NuGet packages we use are quite old, and even
insecure in the case of cURL and OpenSSL (the versions contain known
security flaws that have been addressed by later versions for which no
NuGet packages are available).
The better way to handle this situation is to use the vcpkg system:
https://github.com/Microsoft/vcpkg
The idea is that a single Git repository contains enough supporting
files to build up-to-date versions of a large number of Open Source
libraries on demand, including cURL and OpenSSL.
We integrate this system via four new .bat files to
1) initialize the vcpkg system,
2) build the packages,
4) set up Git's Makefile system to find the build artifacts, and
3) copy the artifacts into the top-level directory
We now also completely convert the pathname exported in the
%msvc_bin_dir_msys% variable to MSYS format with forward slashes rather
than a mixture of forward and back slashes.
This solves an obscure problem observed by some developers:
[...]
http-push.c
CC remote-curl.o
remote-curl.c
* new script parameters
GEN git-instaweb
sed: -e expression #7, char 155: invalid reference \2 on `s' command's RHS
make: *** [Makefile:2023: git-instaweb] Error 1
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The script assumes that we're in the top-level directory of the
checkout. That does not need to be true.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
One time too many did this developer call the `generate` script passing
a `--make-out=<PATH>` option that was happily ignored (because there
should be a space, not an equal sign, between `--make-out` and the
path).
And one time too many, this script not only ignored it but did not even
complain. Let's fix that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The entire idea of generating the VS solution makes only sense if we
generate it via Continuous Integration; otherwise potential users would
still have to download the entire Git for Windows SDK.
So let's just add a target in the Makefile that can be used to generate
said solution; The generated files will then be committed so that they
can be pushed to a branch ready to check out by Visual Studio users.
To make things even more useful, we also generate and commit other files
that are required to run the test suite, such as templates and
bin-wrappers: with this, developers can run the test suite in a regular
Git Bash (that is part of a regular Git for Windows installation) after
building the solution in Visual Studio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When building with Microsoft Visual C, we use NuGet to acquire the
dependencies (such as OpenSSL, cURL, etc). We even unpack those
dependencies.
This patch teaches the test suite to add the directory with the unpacked
.dll files to the PATH before running the tests.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We already unpack the NuGet packages in a certain place, via
compat/vcbuild/Makefile. Let's let Visual Studio use the very same place.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This file is not available in earlier MSVC versions, and it is not
necessary to include it with MSVC, anyway.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Microsoft flipped the Windows Safe Exception Handling default
in VS2013 so that zlib became unacceptable to certain OS versions
(Vista and subsequent 32-bit OS's) without the addition of
the option -SAFESEH:NO.
Provide a switch to disable the Safe Exception Handler when required.
The option ImageHasSafeExceptionHandlers for VS2013 is not available in
earlier versions, so use the SAFESEH:NO linker flag. See
https://msdn.microsoft.com/en-us/library/9a89h429.aspx for
further details.
This has only had limited testing due to the lack of a suitable system.
Helped-by: Yue Lin Ho <b8732003@student.nsysu.edu.tw>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Needed for: test-config; t-dump-split-index; t-dump-untracked-cache;
t-fake-ssh; t-sha1-array; t-submodule-config.
Plus a few spares.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Visual Studio takes the first listed application/library as the default
startup project [1].
Detect the 'git' project and place it the head of the apps list, rather
than the tail.
Export the apps list before libs list for both the projects and global
structures of the .sln file.
[1] http://stackoverflow.com/questions/1238553/
vs2008-where-is-the-startup-project-setting-stored-for-a-solution
"In the solution file, there are a list of pseudo-XML "Project"
entries. It turns out that whatever is the first one ends up as
the Startup Project, unless it’s overridden in the suo file. Argh.
I just rearranged the order in the file and it’s good."
"just moving the pseudo-xml isn't enough. You also have to move the
group of entries in the "GlobalSection(ProjectConfigurationPlatforms)
= postSolution" group that has the GUID of the project you moved to
the top. So there are two places to move lines."
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Delete the duplicated GUID from the generation code for the Visual Studio
.sln project file.
The duplicate GUID tended to be allocated to test-svn-fe, which was then
ignored by Visual Studio / MSVC, and its omission from the build never
noticed.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Visual Studio has this very neat feature that you can get dependencies in
the form of NuGet packages, and even further: you can specify in a project
what NuGet packages it needs. These dependencies can then be fetched via
right-clicking the solution in the Solution Explorer and clicking the
"Restore NuGet Packages" entry.
This feature is so neat, in fact, that we want to support it in Git for
Windows. The idea is that we will be able to provide developers with a
checkout of the Git sources that can be built outside of the Git for
Windows SDK, using *only* Visual Studio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The .sln/.vcproj files were used to define projects up until Visual
Studio 2008, but starting with Visual Studio 2010 the project
definitions are stored in .sln/.vcxproj files (which can also be used
by the MSBuild system).
Let's just copy-edit the generator of the .vcproj files to a new
generator that produces .vcxproj files directly, without forcing Visual
Studio to upgrade the project definitions.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With the recent changes to allow building with MSVC=1, we now pass the
/OPT:REF option to the compiler. This confuses the parser that wants to
turn the output of a dry run into project definitions for QMake and Visual
Studio:
Unhandled link option @ line 213: /OPT:REF at [...]
Let's just extend the code that passes through options that start with a
dash, so that it passes through options that start with a slash, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add an option for capturing the output of the make dry-run used in
determining the msvc-build structure for easy debugging.
You can use the output of `--make-out <path>` in subsequent runs via the
`--in <path>` option.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git's test suite shows tons of breakages unless Git is compiled
*without* NO_ICONV. That means, in turn, that we need to generate
build definitions *with* libiconv, which in turn implies that we
have to handle the -liconv option properly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Generators/ directory can contain spurious files such as editors'
backup files. Even worse, there could be .swp files which are not even
valid Perl scripts.
Let's just ignore anything but .pm files in said directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Upon seeing the '-lcurl' option, point to the libcurl.lib.
While there, fix the elsif indentation.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rather than swallowing the errors, it is better to have them in a file.
To make it obvious what this is about, use the file name
'msvc-build-makedryerrors.txt'.
Further, if the output is empty, simply delete that file. As we target
Git for Windows' SDK (which, unlike its predecessor msysGit, offers
Perl versions newer than 5.8), we can use the quite readable syntax
`if -f -z $ErrsFile` (available in Perl >=5.10).
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 indentically defined in
their respective GIT_VERSION_GEN file DEF_VER variables.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Git's build contains steps to handle internationalization. This caused
hiccups in the parser used to generate QMake/Visual Studio project files.
As those steps are irrelevant in this context, let's just ignore them.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The engine.pl script expects file names not to contain spaces. However,
paths with spaces are quite prevalent on Windows. Use shellwords() rather
than split() to parse them correctly.
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The error message talked about a "lib option", but it clearly referred
to a link option.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add the Microsoft .manifest pattern, and correct the generic 'Debug'
and 'Release' directory patterns which were mechanically adjusted way
back in c591d5f (gitignore: root most patterns at the top-level directory,
2009-10-26) to allow multi-level projects within the Git suite.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
For regular debugging, it is pretty helpful when a debug assertion in a
running application triggers a window that offers to start the debugger.
However, when running the test suite, it is not so helpful, in
particular when the debug assertions are then suppressed anyway because
we disable the invalid parameter checking (via invalidcontinue.obj, see
the comment in config.mak.uname about that object for more information).
So let's simply disable that window in Debug Mode (it is already
disabled in Release Mode).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It is a real old anachronism from the Cogito days to have a
.git/branches/ directory. And to have tests that ensure that Cogito
users can migrate away from using that directory.
But so be it, let's continue testing it.
Let's make sure, however, that git init does not need to create that
directory.
This bug was noticed when testing with templates that had been
pre-committed, skipping the empty branches/ directory of course because
Git does not track empty directories.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Teach the top-level git Makefile to use whatever VS compiler
tool chain is installed on the system.
When building git from the command line in a git-sdk BASH
window with MAKE, the shell environment has environment
variables for GCC tools, but not MSVC tools. MSVC bindings
are only avaliable from the various "VcVarsAll.bat" scripts
run by the "Developer Command Prompt" shortcuts.
Add compat/vcbuild/find_vs_env.bat to the Makefile. It
uses the various "VcVarsAll.bat" scripts in a background
Developer Command Prompt process to compute the proper
environment variables and publish them for use by the Makefile.
[jes: fixed typos, used %SystemRoot% instead of C:\WINDOWS]
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
