Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:73270
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.215.10 cause and error)
To: Kevin Ingwersen <ingwie2000@googlemail.com>
Cc: PHP internals <internals@lists.php.net>
In-Reply-To: <CCD84ABE-CDA8-4027-BDEF-9733AFDF96C9@googlemail.com>
References: <CCD84ABE-CDA8-4027-BDEF-9733AFDF96C9@googlemail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 18 Mar 2014 12:46:19 +0100
Message-ID: <1395143179.9953.55.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] PHP could become more embeddable
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Mon, 2014-03-17 at 22:05 +0100, Kevin Ingwersen wrote:

> This build system is currently learning configuration (checking for
> headers, functions, libraries, tools), generating and downloading of
> files. After this is done, I hope to replicate PHP’s main build system
> int hat way - so I can then include the file from a main file. But in
> order to do this, I need to learn as much as I can about the very
> basic PHP building.
> 
> But this isnt just useful for me. For anyone who wishes to integrate a
> basic PHP engine, this would be some useful knowledge. What to check
> for, what to generate - and then, what to build - to just get a basic
> thing up and running.


The autotools based build system works and takes care of all the
difference in unix systems. And giving users a system which works in a
common way with other software making it easy for unix administrators to
get started. It is also easily extensible for new extensions and the
make process is fast (quick cycle for "vim somefile.c && make" is
important for efficient work, many other build systems spend way more
time finding changes and are recompiling more things maing that process
slow, currently the speed is mostly limited by SAPI linkage)
Unless those things are there it needs really good other benefits to
switch to a different build system.

> As much as I have searched for now, PHP generates a tiny bit of files:
> 
> ./ext/date/lib/timelib_config.h
> ./main/build-defs.h
> ./main/internal_functions.c
> ./main/internal_functions_cli.c
> ./main/php_config.h
> ./TSRM/tsrm_config.h
> ./Zend/zend_config.h
> 
> But, can’t this process be simplified? For example:
> 
> $ cat TSRM/tsrm_config.h 
> #include <../main/php_config.h>
> 
> Why do we even need this file, if it is more or less pointless, as it
> just includes a file at another location?

Since TSRM is a stand-alone library. You can build TSRM without anything
from PHP for usage in other software:

$ mv phpsrc/TSRM TSRM
$ cd TSRM
$ ./buildconf && ./configure && make
$ ls -l .libs/libtsrm.a 
-rw-r--r-- 1 johannes staff 4910 2014-03-18 11:50 .libs/libtsrm.a

I'm not aware of anybody doing this (which doesn't mean anything) but I
know of historic cases where this has been done. This also ensures clear
encapsulation of concerns which makes good design for a larger software
project. Also TSRM is using different license and copyrights.

Similar for date's timelib or even the Zend Engine.

The builtin_functions files have to be generated as we need a way to
register all enabled extensions in specific order (some have
dependencies)

The config files have all the other built time relevant information on
the (mis-)ehaviour of the system which we can't know while writing code
without limiting our supported platforms. (which essentially are:
everything more or less posix-like with a more or less standard c
library and compiler and Windows)

> My goal is to achieve a way to make embedding PHP for others simpler -
> that will incldue adding PHP-CPP. Because its structured so simple,
> that it only comes with a makefile - and you basically could:
> 
> g++ -c src/*.cpp -I. -Iinclude
> ar rcs libphpcpp.a *.o
> 
> Voila, built.
> 
Unfortunately different systems are different, system libraries work
differently, compilers work differently, ... and PHP is using a lot of
those.
> 
> So, to sumarize my points that I somehow tried to explain, but I am
> not very good with wording myself in english - my main language is
> german.
> 
> 	- Autotools is not capable of properly including other projects,
> without forcing more configure calls, which check things over and over
> again.

Yes, the pain for flexibility and compatibility to all sorts of systems.

> 	- Someone may sumarize how to compile the basic PHP by hand - like,
> what files to compile with gcc and which .o’s to put together for a
> basic libphp5.a?

As said, at least in two mails before already: Nobody does, as nobody
cares. If you care ask make. (i.e. make -n or read the Makefile) and as
said nothing of that is a committed interface: file structures, build
system created defines, ... might change on every release.

> 	- Can the build of PHP be made easier, for embedding purpose - by
> refactoring some generations and checks?

It is software, everything is possible, I listed some high level
requirements above a build system for PHP has to deliver. And as said in
a previous mail the suggested path is to use PHP's build system to build
the embed SAPI and use that from some other project (or creating a SAPI)

Yes, this adds a step and a dependency, but PHP is not a simple piece of
self-contained software but a glue on tons ob libraries and system
functions, trying to overcome many system specific anomalies.

Creating a good build system is extremely hard. That's why none exists.

About your system: Your examples are the trivial part. In the examples
you don't seem to have external dependencies. How do you check whether a
library exists or the behavior of a library call? (i.e. "does dlsym on
this platform require a _ before the symbol name ornot?") How check
endianess for encoding routines? How do you check for external tools and
run them (i.e. parser generator)? Oh and compiler features ... does it
know how different compilers use different options?

And as cmake was mentioned in this thread: cmake is a great tool, but it
reduces UNIX-specific freedoms (autocrap allows me to call out to any
program I want at basically any stage) in order to be compatible to
non-UNIX(like) platforms. In the implementations it saw it also often
produced way less efficient Makefiles (which really hurts for a change,
build, test cycle) and is harder to debug (this might be subjective due
to experience but in cmake systems I have to search through tons of
files to find an issue, in out autotools implementation it seems to be
quite more centralized)

johannes