summaryrefslogtreecommitdiff
path: root/contrib/buildsystems
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-29msvc: add a Makefile target to pre-generate the Visual Studio solutionLibravatar Johannes Schindelin1-1/+2
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. If we pre-generate the Visual Studio solution, Git can be built entirely within Visual Studio, and the test scripts can be run in a regular Git for Windows (e.g. the Portable Git flavor, which does not include a full GCC toolchain and therefore weighs only about a tenth of 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 after building the solution in Visual Studio. Note: for this build target, we do not actually need to initialize the `vcpkg` system, so we don't. 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-29contrib/buildsystems: handle options starting with a slashLibravatar Johannes Schindelin1-1/+1
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: also handle -lexpatLibravatar Johannes Schindelin1-0/+2
This is a dependency required for the non-smart HTTP backend. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle libiconv, tooLibravatar Johannes Schindelin1-0/+2
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle the curl library optionLibravatar Philip Oakley1-1/+3
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: error out on unknown optionLibravatar Johannes Schindelin1-0/+2
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: optionally capture the dry-run in a fileLibravatar Philip Oakley1-0/+10
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: redirect errors of the dry run into a log fileLibravatar Philip Oakley1-1/+6
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: ignore gettext stuffLibravatar Philip Oakley1-0/+6
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: handle quoted spaces in filenamesLibravatar Philip Oakley1-3/+4
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: fix misleading error messageLibravatar Philip Oakley1-1/+1
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: ignore irrelevant files in Generators/Libravatar Johannes Schindelin1-1/+1
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> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-29contrib/buildsystems: ignore invalidcontinue.objLibravatar Philip Oakley1-3/+7
Since 4b623d8 (MSVC: link in invalidcontinue.obj for better POSIX compatibility, 2014-03-29), invalidcontinue.obj is linked in the MSVC build, but it was not parsed correctly by the buildsystem. Ignore it, as it is known to Visual Studio and will be handled elsewhere. Also only substitute filenames ending with .o when generating the source .c filename, otherwise we would start to expect .cbj files to generate .obj files (which are not generated by our build)... 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> Signed-off-by: Duncan Smart <duncan.smart@gmail.com> 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>
2013-11-25mark Windows build scripts executableLibravatar Jonathan Nieder3-0/+0
On Windows the convention is to rely on filename extensions to decide whether a file is executable so Windows users are probably not relying on the executable bit of these scripts, but on other platforms it can be useful documentation. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-22msvc: Fix an "unrecognized option" linker warningLibravatar Ramsay Jones1-0/+1
Having recently added support for building git-imap-send on Windows, we now link against OpenSSL libraries, and the linker issues the following warning: warning LNK4044: unrecognized option '/lssl'; ignored In order to suppress the warning, we change the msvc linker script to translate an '-lssl' parameter to the ssleay32.lib library. Note that the linker script was already including ssleay32.lib (along with libeay32.lib) as part of the translation of the '-lcrypto' library parameter. However, libeay32.dll does not depend on ssleay32.dll and can be used stand-alone, so we remove ssleay32.lib from the '-lcrypto' translation. The dependence of ssleay32.dll on libeay32.dll is represented in the Makefile by the NEEDS_CRYPTO_WITH_SSL build variable. Also, add the corresponding change to the buildsystem generator. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-22engine.pl: Fix a recent breakage of the buildsystem generatorLibravatar Ramsay Jones1-3/+5
Commit ade2ca0c (Do not try to remove directories when removing old links, 2009-10-27) added an expression to a 'test' using an '-o' or connective. This resulted in the buildsystem generator mistaking a conditional 'rm' for a linker command. In order to fix the breakage, we filter out all 'test' commands before then attempting to identify the commands of interest. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-17Merge branch 'ef/msys-imap'Libravatar Junio C Hamano1-0/+3
* ef/msys-imap: Windows: use BLK_SHA1 again MSVC: Enable OpenSSL, and translate -lcrypto mingw: enable OpenSSL mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle imap-send: build imap-send on Windows imap-send: fix compilation-error on Windows imap-send: use run-command API for tunneling imap-send: use separate read and write fds imap-send: remove useless uid code
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-10-23MSVC: Enable OpenSSL, and translate -lcryptoLibravatar Marius Storm-Olsen1-0/+3
We don't use crypto, but rather require libeay32 and ssleay32. handle it in both the Makefile msvc linker script, and the buildsystem generator. Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com> Signed-off-by: Erik Faye-Lund <kusmabite@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-Olsen6-0/+1480
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 23:29:47 +0000