When building in out-of-source directory, instead of creating these
build directories right away, this appends them to the list and creates
them at the end of configure phase. These don't need to be created
immediately as no files are generated in these extensions before the
configure phase is finished.
Also, the PHP_ADD_BUILD_DIR is moved after the PHP_NEW_EXTENSION when
the more common $ext_builddir variable is available (the ext/<extension>
isn't available when building with phpize).
This repeats the sync as noted in the GH-13591 and the discussion
https://news-web.php.net/php.internals/124472
The CODEOWNERS file is related to the targeted branch in the pull
request and not only the master branch.
- Added a note to change the earliest supported PHP branch and not only
master branch
- Synced GitHub ID's and paths across the PHP-8.2, PHP-8.3 and master
branches
- Add note how changes here should be analogous to bug fixes
with a link to CONTRIBUTING.md which describes which branch to
target
This regressed when I optimized $wholeText. The previous code used xmlStrcat
which implicitly checked for a NULL argument, but now it's a direct memcpy
which you shouldn't pass null pointers to, although it won't result in a
crash because memcpy doesn't do anything if the length is 0.
This appends source files to the PHP_NEW_EXTENSION call and adds the
possible compilation flag -DZEND_ENABLE_STATIC_TSRMLS_CACHE when
building objects as done on all ext/standard sources already. Also, the
PHP_EXT_DIR Autoconf macro doesn't accept any argument.
- Sync Autoconf syntax
- The PHP_EXT_DIR macro doesn't accept any arguments and since this is
called after PHP_NEW_EXTENSION, the $ext_dir variable can be used
instead.
Instead of defining an empty M4 macro PHP_ALWAYS_SHARED when configuring
extensions in php-src using the main configure.ac, the m4_ifdef can be
used to conditionally call the macro when it is defined (when using
phpize).
This is a left over from 4dee0c4a14.
These definitions are now always done by the config-stubs file. For
phpize builds they are in the phpize.m4 as before.
- PHP_SETUP_LIBXML arguments quoted
- Help texts updated for HAVE_LIBXML, HAVE_DOM, HAVE_XMLREADER,
HAVE_XMLWRITER, HAVE_SOAP, HAVE_SIMPLEXML, and HAVE_XML CPP macros
- Duplicate HAVE_LIBXML symbol definition in PHP_SETUP_LIBXML M4 macro
removed (the HAVE_LIBXML marks that PHP libxml extension is available and
not only that libxml2 library is available)
This macro once had also the 5th argument (the build target), which was
removed via 2a6da0f24c. This quotes all
PHP_SELECT_SAPI arguments and removes the redundant ones. The basic
macro usage help text is moved to the macros section from the obsolete
docs file.
The PHP_DEF_HAVE M4 macro is a simple wrapper around the recommended
AC_DEFINE or AC_DEFINE_UNQUOTED (when shell variables are used in
arguments). This also adds some basic help texts to macros.
simplifying the workflow by just using PQreset which force a new
connection internally, connection process ids ought to be different,
and let the existing checks do the rest.
Using the m4_normalize, the source files can be added more intuitively
using blank-or-newline delimited list of files. This adds also some
basic help text.
When building with readline/libedit installed at non-standard or
non-system paths the check flags also need to be adjusted a bit to be
able to check for the declared variable.
This partially reverts 0956267c08, which
introduced a type incompatibility where an `int` function is assigned
to a `zend_result` function. That yields a level 1 C4133 warning on
MSVC, and usually (e.g. in CI) level 1 warnings are elevated to errors,
so the build fails.[1]
The PHP-8.3 branch and up are uneffected by this, so the upward merges
should be empty.
[1] <0956267c08 (r144587696)>
* ext/dba/tests/setup/setup_dba_tests.inc: sort test output
Iterating through a database with firstkey() and nextkey() is
guaranteed to retrieve all rows, but apparently not in any particular
order. This is causing a test failure for at least one user, so we
steal the sort() approach from GDBM to ensure that the output is
predictable.
* ext/dba/tests/dba_*.phpt: sort expected test output
The actual output is now sorted for consistency, so we need to update
the expected output as well. As a nice side effect, some differences
in the expected outputs for the various engines have been eliminated.
Closes GH-14786
* ext/pgsql/tests/80_bug14383.phpt: sort expected test output
This test uses a routine from ext/dba that now sorts its (actual)
output, so we have to sort the expected output here as well.
* ext/dba/tests/setup/setup_dba_tests.inc: update comment
After doing some more digging, it looks like GDBM isn't the only
engine where the iteration order with firstkey() and nextkey()
might change unexpectedly.
These get the next and previous sibling nodes, respectively.
We can already kind of do this by using the $child array, but that's
inconvenient when actually walking the tree by only using node
instances. Since the class is final, there is no BC break here.
Closes GH-15047.
Using compound literals is conforming to C99 (and up), but not with any
C++ standard. Since the code is in a public header, it might be used
by C++ extensions. Unfortunately, we cannot even used designated
initializers, because these are a C++20 feature, so we stick with
classic C/C++ code.
Closes GH-15100.
