PHPFlüsterer

Compile PHP and/or an extension under Win(x86)

This guide is based on the following official php.net Wiki Page. This guide covers the compile process of

  • PHP (>= 5.5)
  • a PHP-extension (Pecl)

under Windows with Microsoft Visual Studio Express 2012 for Windows Desktop. As result of this operation we will get binaries of PHP for Windows as well as an extension (php_*.dll). We will use the

1
uprofiler

extension (php_uprofiler.dll) as example.

Requirements

Before we start with the compile process we need the following software, libraries, tools and dependencies for this guide:

Preparation / Setup

Install

1
Microsoft Visual Studio Express 2012 for Windows Desktop

. We do not need any special configuration. Just install in default setup.

We need to create directory

1
C:\php-sdk

with the following command


1
mdkir C:\php-sdk

As next step we need to extract the content of

1
php-sdk-binary-tools-20110915.zip

to the previously created directory

1
C:\php-sdk

. As result we have a folder structure like this:


1
2
3
C:\php-sdk\bin
C:\php-sdk\script
C:\php-sdk\share

In directory

1
bin

we will find (hopefully :) the files

1
phpsdk_setvars.bat

and

1
phpsdk_buildtree.bat

as well as some others. But these two files are important for the next step!

Afterwards


1
open VS2012 x86 Native Tools Command Prompt (it's available from the start menu)

and execute the following commands


1
2
3
4
C:  
cd C:\php-sdk\    
bin\phpsdk_setvars.bat    
bin\phpsdk_buildtree.bat phpdev

Extract the

1
PHP sourcecode

to

1
C:\php-sdk\phpdev\vc11\x86\php-source-directory

. As result of this operation you should have a

1
win32

directory within the

1
C:\php-sdk\phpdev\vc11\x86\php-source-directory

directory (

1
C:\php-sdk\phpdev\vc11\x86\php-source-directory\win32

).

Extract the

1
PHP build dependencies

to

1
C:\php-sdk\phpdev\vc11\x86

. As result of this operation you should have a

1
deps

directory within the

1
C:\php-sdk\phpdev\vc11\x86

directory (

1
C:\php-sdk\phpdev\vc11\x86\deps

).

Compile PHP

To compile PHP we need to change the directory to the path of your PHP source code


1
cd C:\php-sdk\phpdev\vc11\x86\php-source-directory

Afterwards we run


1
buildconf

to prepare everything. It makes the configure command available and provide it with the current available flags for compiling. To get an overview of the available build/compiler flags you can use the command


1
configure --help

Based on this information create your configure command like this:


1
configure --disable-all --enable-cli --enable-$remains

Note: The

1
deps

should include the libraries needed to build most the core extensions. However, some other extensions may need additional libraries, header files and helper apps. See libs, fetch the version you need and extract the archive into the

1
deps

directory.

After you have configured how you want to build PHP, you can run


1
nmake

If you want the resulting PHP builds and extensions to be zipped, after

1
nmake

also run


1
nmake snap

The compiled PHP is now available under

1
C:\php-sdk\phpdev\vc11\x86\php-source-directory\Release_TS

. If you ran

1
nmake snap

the zip file will also be here. If you compiled with

1
–disable-zts

the compiled PHP will be under

1
C:\php-sdk\phpdev\vc11\x86\php-source-directory\Release

.

Recompile after changes

If we want to compile PHP again – after we did some changes for example – we need to clean up old compiled binaries, objects, deps first. This is done with the following commands.

Change to PHP source directory


1
cd C:\php-sdk\phpdev\vc11\x86\php-source-directory

and call the cleanup command


1
nmake clean

If you need to update the

1
configure

script


1
buildconf --force

Afterwards create your

1
makefile


1
configure --disable-all --enable-cli --enable-$remains

And now start compile again


1
nmake

Adding an extension (PECL and non-PECL)

Theoretically it doesn’t matter which type of extension you are about to compile. If it is not a PECL extension you will just need to do some extra steps. But in general the compile process is similar to a PECL extension. So for this example we are using the non-PECL extension

1
uprofiler

.

Navigate to the

1
x86

directory:


1
cd C:\php-sdk\phpdev\vc11\x86

Create a directory named

1
pecl

:


1
mkdir C:\php-sdk\phpdev\vc11\x86\pecl

Extract the previously downloaded archive

1
uprofiler-master.zip

in some temporary directory and put the content of the contained

1
extension

directory into


1
C:\php-sdk\phpdev\vc11\x86\pecl\uprofiler-X.Y.Z

where x,y and z are the current major (x), minor (y) and release (z) number. If you have downloaded an extensions sourcecode archive directly from PECL you will always find an versioned directory after extracting the archive. Extensions from other sources often does not have an already versioned directory. So we just create one by our own. At the time writing this tutorial

1
uprofiler

‘s most recent version is 0.9.4 (Note: While it will say 0.10.5 when compiled!). So for this example we would create a directory

1
C:\php-sdk\phpdev\vc11\x86\pecl\uprofiler-0.9.4

Now change to PHP‘s source directory


1
cd C:\php-sdk\phpdev\vc11\x86\php-source-directory

and call


1
buildconf

afterwards execute


1
configure --help

The output should now contain a

1
--enable-uprofiler

option.
Configure PHP to compile nothing but the

1
uprofiler

extension.


1
configure --disable-all --enable-cli --enable-uprofiler=shared

Note: We need to compile it “shared” otherwise it will collide with already existing object

1
_getrusage

.


1
nmake

Test the binary with this command


1
php -m

to make sure

1
uprofiler

exists.

Utilities

Resource Hacker

This utility shows dependency information and other assembly information from a DLL. For instance, it shows which version of the Visual C++ Runtime the DLL was linked against.

We can get it here

Startup-Code: Kommentare im Quelltext

Es ist immer wieder ein gerne diskutiertes Thema** “Kommentare im Quelltext”** – allen voran die sogenannten Inline-Kommentare. Das Kommentare sinnvoll sind und in jedem guten Softwareprojekt elementarer Bestandteil sind, dessen sind sich die Mehrheit der Entwicklergemeinde und auch die Projektverantwortlichen mittlerweile eigentlich sicher. Das ist auch schon viel Wert. Doch es gibt sie noch, die andere Seite – Software ohne Kommentare und das bei Projekten die aus tausenden Zeilen Code und einer Vielzahl von Dateien besteht und so groß gewachsen sind, dass man sich in Eigenregie nur schwer einen Reim aus dem machen kann, was man da teilweise vor sich hat. Es ist zum einen wirtschaftlich betrachtet, geradezu fatal solche Projekte nicht umgehend einer großen Review zu unterziehen und entsprechende Gegenmaßnahmen einzuleiten (z.B. basierend auf dem* Pfadfinderprinzip). Einer meiner ersten Arbeitgeber sagte mal zu mir: *”Zu jeder Zeile Code, schreibt man eine Zeile Kommentar”. Das dies nicht für jede geschriebene Zeile gilt, sondern statistisch zu betrachten ist, sollte klar sein. Mal benötigt man zwei Zeilen Kommentar für eine Zeile Code und manchmal eben auch keine. Aber sollte das was der Code macht aus den angrenzenden Kommentaren direkt ersichtlich sein, möglichst in englisch formuliert, so daß jeder Entwickler weltweit in ein Projekt einbezogen werden kann, ohne an die Hand genommen werden zu müssen. Ja richtig, Entwickler könnten auch einfach den Code lesen, den diese auch sicherlich verstehen würden, doch dauert dies sehr viel länger und kostet entsprechend auch mehr – Zeit ist Geld – auch hier – ganz einfach. Wenn allerdings gar nicht oder zu wenig kommentiert wurde, dann wage ich auch zu bezweifeln, dass andere wichtige Grundlagen einer sauberen Code-Basis eingehalten wurden, wie z.B. “…das Bezeichner im Code sprechend formuliert wurden, der Code für sich alleine stehen kann und so aussieht als wäre er von jemanden geschrieben worden, dem dies wirklich wichtig war…”. Da ist sie auch schon die Überleitung zu Uncle Bob. Während ich diese Aussage von ihm durchaus als richtig erachte, halte ich seine Einstellung oder Vorstellung zu/von Kommentaren einfach für nicht richtig. Seine Meinung dazu geht in die Richtung “Guter Code ist so lesbar und bedarf keiner Kommentare” (Kurzübersetzung aus Clean Code). So eine Aussage kenne sonst nur als Ausrede für ein unzureichendes Arbeitsergebnis. Mit Kommentaren addressiert man auf einer ganz anderen Ebene. Es geht um ein optisch erfassbares vom Code gelöstes Element und das ist eben der Kommentar, der auch dann noch verständlich ist, wenn die darunterliegenden Zeilen Code nicht mehr verstanden werden. Achtung! Auch Kommentare sind kein Heilmittel für schlechten Code. Wenn der Code zu komplex wurde oder man bemerkt, dass eine Methode aufgebläht ist (Stichwort SRP) und NUR NOCH durch die geschriebenen Kommentare erklärt werden kann, dann ist dies ein klares Zeichen für ein benötigtes Refactoring. Besonders häufig habe ich die zuvor beschriebene Art Code übrigens vorgefunden, wenn z. B. Unternehmer/Gründer/Entrepreneure (die auch auf die Time-to-Market achten und die auch müssen/sollten), diesen im Auftrag produzieren lassen und von Qualitätsmanagement im Software-Umfeld einfach nichts verstehen, selber keinen technischen Background haben oder eine Mischung aus beiden und ggf. noch weiteren Faktoren. Jedenfalls kann man davon ausgehen, auf solchen Code zu stoßen, wenn es sich um “im Auftrag entwickelte Software” oder um “Startup-Software” handelte. Ich finde den Begriff Startup-Code so passend, dass ich diesen auch beibehalten werde. Ich schreibe gerade noch an einem Kapitel in meinem aktuellen Buchprojekt, für das ich nach einem passenden Begriff für deartigen crappy– oder** legacy-code** gesucht habe der einfach passender ist als das was bisher so gehört hat. Wie sind eure Erfahrungen? Kennt ihr weitere Namen für deartigen Code?  

Open-Source-Entwicklung mit Open-Source-Werkzeugen

Während einem meiner letzten Open-Source-Projekte war selbst ich von den aktuell verfügbaren Werkzeugen und vor allem von deren Funktionsumfang sowie Stabilität überrascht. Es hat für mich den Anschein, als wäre das Open-Source-Umfeld zwar mittlerweile eine großes Feld zum experimentieren und dabei zugänglich für jedermann und doch durch und durch professionell organisiert. Es gibt dabei unzählige kostenlose Angebote, die man für die Entwicklung der eigenen Projekte in Anspruch nehmen kann, um so mit guter Rückendeckung ein professionelles und zeitgemäßes Projekt auf die Beine zu stellen. So habe ich ein wenig recherchiert und möchte euch das Ergebnis meiner Recherche nicht vorenthalten …

Es scheint auch keine Rolle zu spielen, ob man ein PHP-, JavaScript- oder ein Projekt in einer der vielen anderen Programmiersprachen plant. Ich habe bei meinem letzten Projekt Lazyload.js (Loading Framework für JavaScript), welches ich vor wenigen Tagen veröffentlicht habe, zu 100% auf Open-Source-Werkzeuge gesetzt, um als Ergebnis ein neues Open-Source-Werkzeug zu schaffen. Angefangen beim Sourcecode-Management mit git (msysgit – Git for Windows) und dem darauf aufbauenden hosted Service github über die kostenlose IDE Eclipse (+ PHP Development Tools). Für die Unit-Tests kam QUnit zum Einsatz, welches lokal auf meinem Entwicklungsrechner und auch auf der kostenlosen Continuous-Integration-Plattform Travis-CI mit grunt ausgeführt wurde bzw. kontinuierlich wird. Hat man sein Projekt erst einmal fertiggestellt, hat man dann bei github auch noch die Möglichkeit seinem Projekt ein kostenloses Wiki und eine kostenlose Github-Page zu spendieren. So findet die Öffentlichkeit das Projekt einfacher via Google und man hat die Möglichkeit diese Seiten mit einer einfachen Angabe seiner Google-Analytics Tracking-ID auch noch zu vertracken. Durchdachte Lösungen die von A – Z ineinander greifen. Doch Ein klein bischen geschummelt habe ich bei den 100% – denn bei mir kommt seit jeher nur Windows als Betriebssystem in Frage. Dies hat ganz simple Gründe: Windows dient mir als stabile Basis beim Bauen von Software und Linux liefert diese dann in der Regel aus – hier müssten wir also fairer-weise ein paar Prozent abziehen.

Dieses oben skizzierte Szenario war freilich nicht immer schon so denkbar. In den letzten knapp 4 – 5 Jahren ist auch in Deutschland eine fortschreitende Professionalisierung im Bereich Software-Entwicklung spürbar. Sicherlich gibt es Teilbereiche, die schon länger ihren festen Stand in der Software-Entwicklung haben, allerdings ist der Maßstab den ich hier ansetze immer auf das PHP-Umfeld und angrenzende Bereiche bezogen. Bei den angrenzenden Bereichen handelt es sich z. B. um Frontend-Entwicklung (HTML, CSS, JavaScript, …) oder aber auch Design (UX …) und Text. Denn wenn ich von Professionalisierung spreche, dann ist eben auch das gesamte Endprodukt gemeint und dieses besteht in meinem Fall zu 99% aus vorgenannten Teilen – halt klassische webbasierte Applikationen. Diese Professionalisierung macht ganz natürlich auch vor den Open-Source-Projekten nicht halt. Es hat sich so ein kleines, gut funktionierendes Ökosystem entwickelt. Dieser Entwicklung zuträglich ist selbstverständlich auch die Tatsache, dass Entwickler fast in 100% aller Fälle, technikbegeisterte große Kinder sind, die selbstverständlich gerne das neueste “Spielzeug” haben. Diese Spielzeuge findet man als Entwickler im zuvor angedeuteten Ökosystem. Sie kommen in Form von Werkzeugen und tollen Technologien daher. So bedeutet das Entwickeln von Open-Source-Software zwar, dass man, vielleicht abgesehen von Spenden bei großen Projekten, keine Einnahmen generiert und somit “gratis” gibt, was andere vielleicht verkaufen würden, aber eben auch, dass man lediglich keine monetäre Vergütung für die aufgewendete Zeit erhält, sondern Spaß und davon reichlich! Zusätzlich erhält man die Möglichkeit die Entwicklung einer Vielzahl von Bereichen positiv zu beeinflussen und ggf. mit zu verändern.

Unternehmen die nicht in Zeiten des Internet gegründet wurden, oder nicht im Umfeld des Internet tätig sind, haben so ihre Schwierigkeiten dieser Entwicklung und daraus resultierenden zukunftsweisenden Technologien offen gegenüber zu sein. Oft regiert noch das Credo “Das machen wir schon immer so.” (weitläufig auch als Totschlagargument bezeichnet).  Wenige Unternehmen befinden sich auf der anderen Seite und wissen, wie diese neuen Technologien und Werkzeuge gewinnbringend eingesetzt werden können!

So bleibt zu hoffen, dass ein Ergebnis dieser Entwicklung(en) ist, dass die Erfahrung die Entwickler in diesem Umfeld mit neuen Technologien sammeln zurück in die Unternehmen fließt und diese so positiv von außen verändert werden.

« Older posts

Copyright © 2016 PHPFlüsterer

Theme by Anders NorenUp ↑