summaryrefslogtreecommitdiff
path: root/contrib/buildsystems/Generators
AgeCommit message (Collapse)AuthorFilesLines
2019-10-15Merge branch 'js/azure-pipelines-msvc'Libravatar Junio C Hamano1-0/+3
CI updates. * js/azure-pipelines-msvc: ci: also build and test with MS Visual Studio on Azure Pipelines ci: really use shallow clones on Azure Pipelines tests: let --immediate and --write-junit-xml play well together test-tool run-command: learn to run (parts of) the testsuite vcxproj: include more generated files vcxproj: only copy `git-remote-http.exe` once it was built msvc: work around a bug in GetEnvironmentVariable() msvc: handle DEVELOPER=1 msvc: ignore some libraries when linking compat/win32/path-utils.h: add #include guards winansi: use FLEX_ARRAY to avoid compiler warning msvc: avoid using minus operator on unsigned types push: do not pretend to return `int` from `die_push_simple()`
2019-10-06vcxproj: only copy `git-remote-http.exe` once it was builtLibravatar Johannes Schindelin1-0/+3
In b18ae14a8f6 (vcxproj: also link-or-copy builtins, 2019-07-29), we started to copy or hard-link the built-ins as a post-build step of the `git` project. At the same time, we tried to copy or hard-link `git-remote-http.exe`, but it is quite possible that it was not built at that time. Let's move that latter task into a post-install step of the `git-remote-http` project instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-28contrib/buildsystems: fix Visual Studio Debug configurationLibravatar Alexandr Miloslavskiy1-7/+8
Even though Debug configuration builds, the resulting build is incorrect in a subtle way: it mixes up Debug and Release binaries, which in turn causes hard-to-predict bugs. In my case, when git calls iconv library, iconv sets 'errno' and git then tests it, but in Debug and Release CRT those 'errno' are different memory locations. This patch addresses 3 connected bugs: 1) Typo in '\(Configuration)'. As a result, Debug configuration condition is always false and Release path is taken instead. 2) Regexp that replaced 'zlib.lib' with 'zlibd.lib' was only affecting the first occurrence. However, some projects have it listed twice. Previously this bug was hidden, because Debug path was never taken. I decided that avoiding double -lz in makefile is fragile and I'd better replace all occurrences instead. 3) In Debug, 'libcurl-d.lib' should be used instead of 'libcurl.lib'. Previously this bug was hidden, because Debug path was never taken. Signed-off-by: Alexandr Miloslavskiy <alexandr.miloslavskiy@syntevo.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29vcxproj: also link-or-copy builtinsLibravatar Johannes Schindelin1-0/+3
The default location for `.exe` files linked by Visual Studio depends on the mode (debug vs release) and the architecture. Meaning: after a full build, there is a `git.exe` in the top-level directory, but none of the built-ins are linked.. When running a test script in Git Bash, it therefore would pick up the wrong, say, `git-receive-pack.exe`: the one installed at the same time as the Git Bash. 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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: add a backend for modern Visual Studio versionsLibravatar Johannes Schindelin1-0/+385
Based on the previous patches in this patch series that fixed the generator for `.vcproj` files (which were used by Visual Studio prior to 2015 to define projects), this patch offers to generate project definitions for neweer versions of Visual Studio (which use `.vcxproj` files). To that end, this patch copy-edits the generator of the `.vcproj`. In addition, we now use the `vcpkg` system which allows us to build Git's dependencies (e.g. curl, libexpat) conveniently. The support scripts were introduced in the `jh/msvc` patch series, and with this patch we initialize the `vcpkg` conditionally, in the `libgit` project's `PreBuildEvent`. To allow for parallel building of the projects, we therefore put `libgit` at the bottom of the project hierarchy. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: urlencode '<' and '>' when generating VC projectsLibravatar Johannes Schindelin1-0/+8
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: do not configure VCWebServiceProxyGeneratorToolLibravatar Johannes Schindelin1-12/+0
It is not necessary, and Visual Studio 2015 no longer supports it, anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: list git.exe first to be startup projectLibravatar Philip Oakley1-14/+19
Visual Studio takes the first listed application/library as the default startup project [1]. Detect the 'git' project and place it at the head of the project list, rather than at 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> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29Vcproj.pm: auto-generate GUIDsLibravatar Johannes Schindelin1-57/+9
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 upcoming Vcxproj generator (to support modern Visual Studio versions) is based on the Vcproj generator and it is better to fix this here first. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30Make the MSVC projects use PDB/IDB files named after the projectLibravatar Sebastian Schuberth1-0/+4
Instead of having all PDB files for all projects named "vc90.pdb", name them after the respective project to make the relation more clear (and to avoid name clashes when copying files around). Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Acked-by: Marius Storm-Olsen <mstormo@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-29Make just opening the generated MSVC solution file not modify itLibravatar Sebastian Schuberth1-31/+11
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> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-29Make generated MSVC solution file open from Windows ExplorerLibravatar Sebastian Schuberth1-1/+4
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> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-29generators/vcproj.pm: remove UNICODE from buildLibravatar Michael Wookey1-4/+4
Defining UNICODE for MSVC IDE builds results in certain Win32 WIDE API's receiving ANSI strings. The result of which is an invalid use of the API and will end in either data corruption or an application crash. Prevent the use of WIDE API's when building with the MSVC IDE for compatibility with msysGit. Signed-off-by: Michael Wookey <michaelwookey@gmail.com> Acked-by: Marius Storm-Olsen <mstormo@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-18Add scripts to generate projects for other buildsystems (MSVC vcproj, QMake)Libravatar Marius Storm-Olsen2-0/+828
These scripts generate projects for the MSVC IDE (.vcproj files) or QMake (.pro files), based on the output of a 'make -n MSVC=1 V=1' run. This enables us to simply do the necesarry changes in the Makefile, and you can update the other buildsystems by regenerating the files. Keeping the other buildsystems up-to-date with main development. The generator system is designed to easily drop in pm's for other buildsystems as well, if someone has an itch. However, the focus has been Windows development, so the 'engine' might need patches to support any platform. Also add some .gitignore entries for MSVC files. Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-07 00:42:09 +0000