PHP SDK is a tool kit for Windows PHP builds.
The PHP SDK itself and the SDK own tools and code are licensed under the BSD 2-Clause license. With the usage of the other tools, you accept the respective licenses.
The PHP SDK 2.0+ is compatible with PHP 7.0 and above. The compatibility with older versions is kept, also available from the legacy branch. The toolset was significantly revamped. Newer tools are now available, better workflows are now possible. The toolset consists on a mix of the hand written scripts, selected MSYS2 parts and standalone programs.
Visual C++ 2015
orVisual C++ 2017
must be installed prior SDK usage- if
Cygwin
is installed, please read notes in the pitfalls section - if a 64-bit build is intended, a 64-bit system is required. Cross compilation of 64-bit on 32-bit system is not supported at the moment
- The PHP SDK was successfully tested on Windows 7 or later, earlier versions might work but are not recommended
All the tools included are either scripts or 32-bit binaries. They are therefore runable on any of x86 or x64 supported Windows system.
- starter scripts, named phpsdk-<crt>-<arch>.bat
phpsdk_buildtree
- initialize the development filesystem structurephpsdk_deps
- handle dependency librariesphpsdk_dllmap
- create a JSON listing of DLLs contained in zip filesphpsdk_pgo
- run PGO trainingphpsdk_version
- show SDK versiontask.exe
- wrapper to hide the given command line
bison
3.0.4,re2c
1.0.2,lemon
awk
,gawk
,sed
,grep
diff
,diff3
,patch
md5sum
,sha1sum
,sha224sum
,sha256sum
,sha384sum
,sha512sum
7za
,zip
,unzip
,unzipsfx
wget
,pwgen
These are not included with the PHP SDK, but might be useful. While Visual C++ is the only required, the others might enable some additional functionality. Care yourself about making them available on your system, if relevant.
Git
- useful for PHP source managementCppcheck
- used for static analysisclang
- useful for experimental builds and for static analysisICC
- useful for experimental buildsConEmu
- console emulator with tabs and more
The PHP SDK should be unzipped into the shortest possible path, preferrably somewhere near the drive root.
Usually, the first step to start the PHP SDK is by invoking one of the suitable starter scripts. This automatically puts the console on the correct environment relevant for the desired PHP build configuration.
It is not required to hold the source in the PHP SDK directory. It could be useful, for example, to simplify the SDK updates.
git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk
cd c:\php-sdk
git checkout php-sdk-2.0.12
or later- invoke
phpsdk-vc15-x64.bat
phpsdk_buildtree phpmaster
git clone https://github.com/php/php-src.git && cd php-src
, or fetch a zipballphpsdk_deps --update --branch master
, usephpsdk_deps --update --branch X.Y
for a non master branch- do the build, eg.
buildconf && configure --enable-cli && nmake
More extensive documentation can be found on the wiki.
git clone https://github.com/Microsoft/php-sdk-binary-tools.git c:\php-sdk
- follow the instructions on the PHP wiki page
A script called phpsdk-local.bat has to be put into the PHP SDK root. If present, it will be automatically picked up by the starter script. A template for such a script is included with the PHP SDK. This allows to automatically meet any required preparations, that are not foreseen by the standard PHP SDK startup. Be careful while creating your own phpsdk-local. It's your responsibility to ensure the regular PHP SDK startup isn't broken after phpsdk-local.bat was injected into the startup sequence.
The starter scripts can be also easy integrated with the consoles other than standard cmd.exe. For the reference, here's an example ConEmu task
C:\php-sdk\phpsdk-vc15-x64.bat -cur_console:d:C:\php-sdk\php72\vc15\x64\php-src
An elementary functionality to run unattended builds is included. See an example on how to setup a simple unattended build task in the doc directory.
Be aware, that starter scripts always start a new shell. Scripts intended to run as a task need to be passed with -t
argument to a starter script.
- backup phpsdk-local.bat
- backup the source trees and any other custom files in the PHP SDK root, if any present
- move the PHP SDK folder into trash
- download, unpack and the new PHP SDK version under the same path
- move the custom files back in their respective places
If the PHP SDK is kept as a git checkout, merely what is needed instead is to git fetch and to checkout an updated git tag.
The SDK tools are based on the KISS principle and should be kept so. Basic tools are implemented as simple batch script. The minimalistic PHP
is available for internal SDK purposes. It can be used, if more complexity is required. A suitable PHP binary is bound with the PHP SDK. If you have an idea for some useful tool or workflow, please open a ticket or PR, so it can be discussed, implemented and added to the SDK. By contributing an implementation, you should also accept the SDK license.
As of the version 2.1.0, the SDK includes a tool for the PGO optimization. Several training cases are included by default, which are based on the real life opensource applications. The PGO optimization can give an overall speedup up to 30%. The work on adding more training scenarios for the widely used opensource apps is ongoing. If you have a training scenario to share, please create a PR to this repo. Any new training cases are thoroughly validated through the extensive performance tests.
- the pgo folder in the SDK root dir contains templates and scenarios for PGO training
- adjust and execute doc/phpsdk_pgo_prep_elevated.bat.example to open ports required for PHP SDK training servers
- run
phpsdk_pgo --init
- compile PHP configured using
--enable-pgi
- run
phpsdk_pgo --train
- run
nmake clean-pgo
- rebuild PHP
--with-pgo
A custom scenario can be used to produce a custom PHP binary dedicated to an arbitrary application.
The existing training cases can be found in pgo/cases. Assumed the case would be named myapp
, the general steps to setup were
- create the case directory under
pgo/cases/myapp
- create
pgo/cases/myapp/phpsdk_pgo.json
with the necessary definitions - create
pgo/cases/myapp/nginx.partial.conf
with a partial NGINX template - create
pgo/cases/myapp/TrainingCaseHandler.php
with a class as defined in the interface
After a training case is implemented and put under pgo/cases
, the work environment needs to be reinitialized. The tool puts all the training data and necessary applications under pgo/work
. Rename or remove that directory and rerun phpsdk_pgo --init
.
To skip a training case, add a file named inactive
into the case folder.
- SDK or PHP sources put into paths including spaces might cause issue.
- SDK or PHP sources put into too long paths, will cause an issue.
- If Cygwin, MSYS2 or MinGW flavors are exposed in global PATH, it might cause issues. If it's unavoidable, ensure SDK preceeds it on the PATH.
- When fetching the binary SDK from git, git
core.autocrlf
configuration directive set tofalse
is recommended. - Tools, based on MSYS2, only accept paths with forward slashes.
- Both Visual C++ toolset and the Windows SDK components have to be installed for the PHP SDK to work properly.
- The VC++ toolset is still requried, even if another compiler, fe. clang, is intended to be used.
task.exe
is not a console application, some systems might not propagate exit code except the batch is explicitly run fromcmd /c
, etc.7za
should be prefered overunzip
andzip
for compatibility reasons.