There are three reasons for this change:
* It's consistent with MSYS2, which already renamed console.exe to
winpty.exe.
* winpty.exe is less likely to clash with another program.
* winpty.exe is easier to search for online. If someone unfamiliar with
winpty is asked to run console.exe, they might have a hard time figuring
out where console.exe comes from.
The old behavior can be restored by passing UNIX_ADAPTER_EXE=console.exe
to `make`, or by simply renaming the binary after-the-fact, or with
`alias`, etc.
The gyp file already worked this way, but now the Makefile does too.
The motivation is to let the shared source files have different error
handling behavior (e.g. assert/ASSERT/stderr-print/abort/exception) in
winpty.dll and the other targets.
Currently, when a header file is removed (or renamed), there is a stale
dependency file still referring to the header, and GNU make aborts, because
the header is missing. Attempt to work around this by adding a pattern
rule to generate any header in `src/`. The rule prints a warning message.
The C source file whose header was missing will be recompiled because a
dependency was rebuilt. Once it is, the removed header should be removed
from the dependency file.
(Aside: FWIW, the "ninja" build tool knows directly about depfiles, and it
does not have this problem.)
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.
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.
* Previously, "make tests install" would also copy trivial_test.exe and
trivial_test.d to /usr/local/bin.
* The `install` tool seems to be the conventional way of installing files.
Setting permissions when copying to /usr/local/bin seems like a good
idea.
* Invoke install with -s to strip the symbol tables when they're
installed.
* This avoids a name conflict with an existing unrelated project.
* I think winpty is a better name anyway. (i) It's more obviously
Windows-related. (ii) I think it more accurately describes what it
does. A "pseudo-console" ought to mirror the console API and allow
replacing the implementation built-in to Windows. This project is only
trying to provide functionality similar to using the master interface of
a Unix pty, but for native console programs.
My plan now is to integrate the PseudoConsole with Cygwin and MSYS ptys,
with initial focus on Cygwin. I think I'll keep the separate Agent and DLL
binaries, and they'll continue to be native Win32 binaries. I don't want
to have two build systems (qmake vs whatever MSYS/Cygwin uses), and since
I'd like to remove the Qt dependency anyway, I'm trying to switch to
makefiles.