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
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
This patch adds missing newlines, trims multiple redundant final
newlines into a single one, and trims redundant leading newlines.
According to POSIX, a line is a sequence of zero or more non-' <newline>'
characters plus a terminating '<newline>' character. [1] Files should
normally have at least one final newline character.
C89 [2] and later standards [3] mention a final newline:
"A source file that is not empty shall end in a new-line character,
which shall not be immediately preceded by a backslash character."
Although it is not mandatory for all files to have a final newline
fixed, a more consistent and homogeneous approach brings less of commit
differences issues and a better development experience in certain text
editors and IDEs.
[1] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_206
[2] https://port70.net/~nsz/c/c89/c89-draft.html#2.1.1.2
[3] https://port70.net/~nsz/c/c99/n1256.html#5.1.1.2
Since there is no need to patch libsqlite3 for our purposes, and since
libsqlite3 ≥ 3.3.9 (which is our current requirement) is widely
available on distros, there is no reason anymore to bundle the library.
Besides removing the bundled libsqlite, and adapting the configuration
respectively, we also fix the use of the SQLITE_ENABLE_COLUMN_METADATA
compile time constant to detect whether sqlite3_column_table_name() is
available by a working feature detection (otherwise bug_42589.phpt
would fail). We also skip bug73068.phpt for libsqlite 3.11.0 to
3.14.1 which have a bug (<https://sqlite.org/src/info/ef360601>).
We also completely drop support for the obscure pdo_sqlite_external
extension (which could have been enabled on Windows only by passing
`--pdo-sqlite-external` to configure), since it is not needed anymore.
Furthermore, we remove references to the bundled libsqlite from
Makefile.gcov, CONTRIBUTING.md and README.REDIST.BINS.
