summaryrefslogtreecommitdiff
path: root/contrib/buildsystems/Generators
AgeCommit message (Collapse)AuthorFilesLines
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-12-14 02:46:01 +0000