Automatically generating and using test INI files is supported for
in-tree build (`buildconf`) for a long time, and this can make sense
for phpize builds too, especially when the build extension is a zend
extension, so it can be properly loaded.
Thus we make `--enable-test-ini` and `--with-test-ini-ext-exclude`
available for phpize, but default to false for full BC.
Closes GH-8787.
On Windows, the contents of the CREDITS files are passed to rc.exe via
the command line. To avoid undesired behavior, we need to escape some
characters, most notably `<` (which is sometimes used in CREDITS to
enclose mail addresses), which otherwise is interpreted as redirection
operator, resulting in the hard to understand "The system cannot find
the file specified."
Even more dangerous is not properly escaping percent signs, which makes
it possible for a malicious CREDITS file to inject the values of
environment variables of the build system into the generated binaries.
This is particularly bad, because as of Windows Vista, the comments can
no longer be inspected via explorer.exe, although the binaries still
contain these comments.
We also cater to double-quotes, which need to be escaped as `\"\"` in
this context.
Closes GH-8767.
Newer MSVC versions support the `inline` keyword, so we do not need to explicitly define it. We also shouldn't define `inline` to `__forceinline`, as we already have `zend_always_inline` to indicate this requirement.
1. Update: http://www.php.net/license/3_01.txt to https, as there is anyway server header "Location:" to https.
2. Update few license 3.0 to 3.01 as 3.0 states "php 5.1.1, 4.1.1, and earlier".
3. In some license comments is "at through the world-wide-web" while most is without "at", so deleted.
4. fixed indentation in some files before |
We must not redefine the version "constants" for phpize builds, because
these have already generated in phpize.js, from where we pass these
variables forward to configure.js.
We also add `PHP_EXTRA_VERSION` and `PHP_VERSION_STRING` to the files
for completeness.
Closes GH-6419.
`configure` for `phpize` builds on Windows creates Makefile and
config.pickle.h and includes the latter via the command line option
`/FI`. That implies that config.pickle.h is always included before
config.w32.h, which means that standard definitions always override
extension specific definitions, while it should be the other way round.
Therefore, we change the inclusion order by including config.pickle.h
at the end of config.w32.h if the former is available, and also make
sure to avoid any potential C4005 warnings by `#undef`ining the macros
before defining them.
Closes GH-6269.
Checking the linker compatibility with extranous `ImageLoad()` calls is
possible, but unnecessary, since the modules are either already loaded
or loaded shortly afterwards, so that we can get the required
information directly from the module handles. And actually, doing
`ImageLoad()` as well as `LoadLibrary()` leaves a tiny room for a race
condition, because both functions will lookup the module in the search
path, so there is no *guarantee* that both are dealing with the same
module. Dropping the `ImageLoad()` calls also has the advantage to no
longer face the issue reported in bug #79557. A very minor additional
advantage is that we no longer have to link against Imagehlp.dll.
Furthermore, there is no need to check for CRT compatibility multiple
times, so we can simplify the signature of `php_win32_crt_compatible`,
and at the same time clean up main.c a bit.
These changes require to change the signature of the exported
`php_win32_image_compatible` and `php_win32_crt_compatible` functions,
which now expect a `HMODULE` and nothing, respectively, instead of the
module name.
Some extension may need to retrieve the `gdImagePtr` from an `GdImage`
object; thus, we export the respective function. To not being forced
to include gd.h in php_gd.h, we use the opaque `struct gdImageStruct *`
as return type.
We also rename php_gd2.dll to php_gd.dll, since there's not really much
point in giving the DLL a version number, since there is no php_gd.dll
for years (if there ever has been). Renaming, on the other hand,
matches the name on other systems (gd.so), and allows to actually use
`ADD_EXTENSION_DEP()`.
Formerly, this had to be enabled by passing the configuration flag
`--enable-crt-debug`; now it can be enabled by setting the environment
variable `PHP_WIN32_DEBUG_HEAP`. The advantage is that it is no longer
necessary to do separate builds, at the cost of a very minor
performance penalty during process startup.
Building with `/W3` shows an awful lot of warnings on Windows, so it's
really hard to spot the more important ones. Since it is not possible
to override the hard-coded `/W3`, we drop it altogether, so MSVC uses
the default `/W1`. Users are encouraged to increase the warning level
via the environment variable `CFLAGS` before doing configure.
We also enable `/WX` (treat warnings as errors) for AppVeyor CI, using
`/W1` for now, since otherwise the build would fail.
In the buildconf and configure batch files, Windows' cscript utility was being
run without the /e:jscript flag. This works on systems that have not had the
default .js file association changed, but if .js has been re-associated to
(say) an IDE, the batch files fail with the error message:
Input Error: There is no script engine for file extension ".js".
ASan instrumentation does not support the MSVC debug runtime, but still
it does not make sense to enable optimizations for such builds, since
they are not meant for production usage anyway, and although memory
corruption issues are still found in optimized builds, the generated
diagnostics are close to being useless, and apparently sometimes even
outright wrong. Therefore, we disable all optimizations for ASan
instrumented builds.
We also introduce and use `ZEND_WIN32_NEVER_INLINE` for ASan enabled
builds to avoid inlining of functions, so we get even better
diagnostics.
While it is already possible to *set* CFLAGS and LDFLAGS (actually all
variables) from the environment for `nmake` (by passing the `/E`
option), it is not possible to *add* any (C|LD)FLAGS, which can be
useful in some cases. Instead of allowing this for `nmake`, we add
support for additional custom (C|LD)FLAGS to `configure`, similar to
how that works on Linux, so one could actually write:
````
set CFLAGS=foo & set LDFLAGS=bar & configure
````
This also allows us to use these flags during configure.
Since Autoconf 2.53 the AC_INIT call with only a single argument has
been made obsolete and now includes several other optional arguments to
make installation experience a bit better by providing program version
and links to the project in the `./configure -h` output. This patch also
updates win build version. The phpize.m4 AC_INIT has been updated with
the call without arguments.
For the latest versions, refer also to the Visual Studio version, not to
the exact toolset version. The latest Visual Studio versions are moving
fast and the method existed previously is not sutable to keep up
anymore. Instead of refering to the exact toolset, it refers to the
Visual Studio version and implies the latest toolset available there.
That is still not ideal, another situation can arise where VS version is
not changed, but the toolset version is. It might be better to refer to
it a generic way in the future or even omit at all, and improve the
internal compatibility checks instead.
This patch joins two very much related pieces of docs together in a
single file dedicated to all sorts of contributing info.
Some more changes:
- Branches info copied from the current master branch
- LXR and bonsai info removed
- Duplicated info reduced a bit
- Security branch updated to 7.1
- Refactor intro for Git commit rules
- Updated README.GIT-RULES file usage in win32/build/confutils.js
- Refactored configure.ac
