* Remove the "version suffix" and BUILD_INFO.txt mechanisms, which I
believe no one uses except winpty itself. Instead, a suffix can be
added in the VERSION.txt file.
* Instead of passing the version and commit info as a preprocessor macro
when building every C++ file, write the info into a GenVersion.h
header that is only included by WinptyVersion.cc.
* Instead of writing a BUILD_INFO.txt in ship.py, pass COMMIT_HASH=<hash>
to make.
These changes accomplish two things:
* People who build a tag from source won't see a "<ver>-dev" suffix
anymore.
* Changing the version or the commit will correctly rebuild the version
object files (and only those object files). It will also relink every
binary.
Fixes https://github.com/rprichard/winpty/issues/72
The variables can be specified on the make command-line instead, and the
user could have unrelated variables that happen to have the name winpty
is using.
I verified that MSYS2 is passing UNIX_ADAPTER_EXE and PREFIX on the
command-line. ship/ship.py already passes PREFIX on the command-line.
Previously, for each object file, the Makefile spawned a subprocess for
each of: echo, mkdir, dirname, and git. Most of these can be eliminated:
- echo: The gmake function $(info ...) is mostly good enough -- it
affects the --dry-run/-n output, which might be undesired.
- mkdir: We only need to invoke mkdir once per directory. It's tricky
to get the optimal behavior, but it's possible to do better than before.
- dirname: The gmake function $(dir ...) is good enough.
- git: only needed once per build, to get the commit hash.
MinGW-w64 is still supported, as is the MinGW compiler distributed by
mingw.org.
Cygwin's MinGW toolchain uses the 4.0-1 mingw-runtime package by
default, which appears to correspond to the "WSL-4" 4.x version of the
MinGW project's mingwrt packages. (The version numbers in the
/usr/i686-pc-mingw32/sys-root/mingw/include/_mingw.h file are also
consistent with this theory.)
The WSL-4 branch was repudiated by the MinGW project as a mistake [1].
The MinGW project claims no responsibility for Cygwin's MinGW packages
[2]. There were several releases in short succession [3]:
4.0.3 2013-09-22
4.0.2 2013-09-15
4.0.1 2013-09-14
4.0.0 2013-08-23
There have been no 4.x releases since then, though there have been more
3.x releases (3.21 and 3.21.1). The FILE_FLAG_FIRST_PIPE_INSTANCE bug
that this project has worked around was fixed in 4.0.3 [4], which was
never propagated to the Cygwin package.
The MinGW packages were apparently orphaned on 2014-09-18 [5] and are
still orphaned [6].
The g++ compiler in this package is still 4.7.3 (released on 2013-04-11),
which is almost three three years old. While writing the "GenRandom"
module, I hit a bug where a non-static data member initializer of
pointer-to-function-type segfaulted the compiler. (gcc seemed to have
confused the field with a pure virtual method.)
[1] http://sourceforge.net/p/mingw/bugs/1673/#5260/41ec
[2] http://sourceforge.net/p/mingw/bugs/1673/#2556/35d4
[3] http://sourceforge.net/projects/mingw/files/MinGW/Base/mingwrt/
[4] http://sourceforge.net/p/mingw/bugs/2050/
[5] https://cygwin.com/ml/cygwin/2014-09/msg00289.html
[6] https://cygwin.com/cygwin-pkg-maint
Now that the InputHandler thread blocks with select, in addition to the
main thread that also blocks with select, winpty has hit a bug in the
original MSYS where select returns EAGAIN. select is not supposed to fail
with that error (EAGAIN doesn't make much sense as a select error). Add
a workaround just for the original MSYS.
* Remove GIT_REVPARSE_WORKS, which is never used
* Rename the shell variables {UNIX,MINGW}_GPP to {UNIX,MINGW}_CXX to
match the config.mk variable names.
There is a "version suffix" that defaults to "-dev". A maintainer could
change the suffix (or remove it) by invoking make:
make BUILD_SUFFIX=-foo
make BUILD_SUFFIX=
It can also be changed in gyp builds:
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=-foo
gyp winpty.gyp --depth=1 -D BUILD_SUFFIX=
If git cannot be executed, the string "none" is used for the commit hash.
* This change reduces the total build time from about 14 seconds to about
9 seconds on my computer.
Also:
* Consolidate all the intermediate files into the build directory to
reduces clutter.
* Allow specifying UNIX_ADAPTER_EXE to make. Perhaps this will be helpful
to the MSYS2 fork, which renames console.exe to winpty.exe. (I like
the renaming, but I don't know about the other winpty users. Maybe
I'll make the change after I've put out another stable release...)
* Rename the WINPTY define to COMPILING_WINPTY_DLL define. The longer
name is clearer. I define the macro inside libwinpty/winpty.cc, so the
build system no longer needs to. (I removed the define from
winpty.gyp.)
* Consolidate config-unix.mk and config-mingw.mk into config.mk. The
separation was previously necessary because each file had a conflicting
definition of CXX.
* Rename the UNIX_LDFLAGS_STATIC_LIBSTDCXX macro to UNIX_LDFLAGS_STATIC,
because libstdc++ isn't the only thing I'm linking statically.
* MSYS is 32-bit only.
* MSYS2 and Cygwin are either 32-bit or 64-bit. On 64-bit MSYS2/Cygwin,
we use the same architecture for all generated binaries.
* Prefer mingw-w64 to mingw. mingw-w64 seems to be more up-to-date.
It is the only option for 64-bit Windows, so stop looking for
x86_64-pc-mingw32-g++.
* Also pass -static when linking binaries. Otherwise, a pthreads DLL
is linked dynamically.
* At least for now, I'm shipping Cygwin/MSYS binaries. On Cygwin (but
not MSYS), the console.exe executable previously linked dynamically
to cyggcc_s-1.dll and cygstdc++-6.dll.
Linking dynamically with cygstdc++-6.dll seems risky for a binary
not distributed by Cygwin, because G++'s Windows ABI is unstable, at
least as of G++ 4.7, which turned on the __thiscall calling
convention. If a binary I ship ever comes into contact with a
4.7-versioned cygstdc++-6.dll, then my binary will (very likely)
segfault.
So far, I've only observed this ABI incompatibility with MinGW,
where a sufficiently upgraded MinGW configuration comes with a
libstdc++-6.dll that is completely incompatible with every previous
libstdc++-6.dll, so that every program built against the older
libstdc++-6.dll segfaults immediately. For now, Cygwin seems stuck
at G++ 4.5, and my impression (possibly incorrect), is that G++'s
Windows ABI was stable prior to 4.7. I think G++'s Linux ABI is
stable. Presumably Cygwin will eventually update its compiler,
though, so it makes sense to fix the problem early.
I believe I originally chose to dynamically link the libraries
because it was the default behavior, and I was afraid that a
non-default option would break something. It turns out that
linking statically with cygstdc++-6 *does* break something -- it
causes linker errors if the code uses std::cerr. The workaround
is not to use std::cerr. This is not a problem for the
unix-adapter, which already has to put up with MSYS' gimpy G++ 3.4
compiler.
* Move the Cygwin/MSYS detection logic from config-*.mk into this new
script.
* Recognize either the 32-bit MinGW or the 32-bit MinGW-w64 compiler
driver for Cygwin.
