php5: refactor variants into separate ports

[ryandesign (Ryan Carsten Schmidt)]

There are too many variants in the php5 port and I want to eliminate most if not all of them by breaking them out into separate ports.

Variants are inconvenient because if you want to add one you have to rebuild the whole port, which for php5 takes some time. Also, ports can't depend on variants of other ports (#126). Also, once we start building and distributing binaries of ports, each additional available variant increases exponentially the number of combinations that would need to be built. If we instruct the build server only to build a few common variant combinations, then users of other variants would miss out on the benefits of using binaries.

The php5 port has two kinds of variants: SAPI variants and extension variants. The SAPIs are cli (always on), fastcgi (+fastcgi variant; becomes always on in php 5.3.0), and apache (which should, considering #14001 and #17678, be available in flavors for Apple Apache 1 (Mac OS X < 10.5), MacPorts Apache 1 (apache port), Apple Apache 2 (Mac OS X >= 10.5), MacPorts Apache 2 (apache2 port), and MacPorts Apache 2.0 (apache20 port). The extension variants enable specific PHP functionality such as access to databases, graphics libraries, etc. We should begin by moving the extension variants to separate ports, so that once we start breaking the SAPIs into their own ports, they won't have to duplicate all the extension variants.

Precedent: FreeBSD has separate ports for separate php5 extensions. Their system seems to be based on Makefiles and their php5 extension ports just include a master php5 extension Makefile (​Makefile.ext); for MacPorts, this should be a portgroup. And all the special-case code for the various extensions in their Makefile.ext would be overrides in the individual extension portfiles for us.

Some more info on compiling php extensions as dynamic libraries instead of statically building it into the php binaries is ​here. Note the comment from Nico about using "make build-modules" instead of just "make" to make the build go more quickly.

We'll also need to compile php to load extra .ini files from an additional directory, like ${prefix}/etc/php.d, where each php extension port can put a pre-written .ini file which enables that module. I believe this is the "--with-config-file-scan-dir" configure option.

[alakazam@…]

Variants are inconvenient because if you want to add one you have to rebuild the whole port, which for php5 takes some time. Also, ports can't depend on variants of other ports (#126). Also, once we start building and distributing binaries of ports, each additional available variant increases exponentially the number of combinations that would need to be built. If we instruct the build server only to build a few common variant combinations, then users of other variants would miss out on the benefits of using binaries.

I think these are good arguments in favor of having separate ports for php5 extensions, and I agree that this would be interesting, easier, and faster to build. Since the php5 distribution package seems to support incremental compilation/activation/usage of extensions, we should probably do this.

I'm not sure about SAPI variants though, as I think it would be more complicated for users to find the correct port to build (not using variants when they're the logical choice from the user's pov isn't ideal imho).

We'll also need to compile php to load extra .ini files from an additional directory, like ${prefix}/etc/php.d, where each php extension port can put a pre-written .ini file which enables that module. I believe this is the "--with-config-file-scan-dir" configure option.

I think this would be interesting even for existing php5 extensions (eaccelerator, xdebug, etc.) which currently need to be manually enabled and disabled when un/installed.

[ryandesign (Ryan Carsten Schmidt)]

Replying to alakazam@…:

I'm not sure about SAPI variants though, as I think it would be more complicated for users to find the correct port to build (not using variants when they're the logical choice from the user's pov isn't ideal imho).

We can discuss this later. There is still much work to do first on breaking the extension variants out into separate ports.

We'll also need to compile php to load extra .ini files from an additional directory, like ${prefix}/etc/php.d, where each php extension port can put a pre-written .ini file which enables that module. I believe this is the "--with-config-file-scan-dir" configure option.

I think this would be interesting even for existing php5 extensions (eaccelerator, xdebug, etc.) which currently need to be manually enabled and disabled when un/installed.

Yes, I intend for the php5pecl portgroup to handle that for those ports.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

Replying to alakazam@…:

I'm not sure about SAPI variants though, as I think it would be more complicated for users to find the correct port to build (not using variants when they're the logical choice from the user's pov isn't ideal imho).

We can discuss this later. There is still much work to do first on breaking the extension variants out into separate ports.

However, you can read some more comments from me in #19336 on why I do think separate ports for each SAPI is the right move.

[(none)]

Milestone Port Enhancements deleted

[ryandesign (Ryan Carsten Schmidt)]

• r53651: updated php5extension portgroup to support building bundled extensions

[ryandesign (Ryan Carsten Schmidt)]

First round of refactoring:

• r53781: new ports php5-curl php5-gd php5-gmp php5-imap php5-mcrypt php5-pspell php5-readline php5-tidy php5-xsl php5-zlib
• r53797: remove the above features from php5, php5-devel

[ryandesign (Ryan Carsten Schmidt)]

Second round of refactoring:

• r54563: updated php5extension to support ports with multiple extensions, like the below
• r54564: new port php5-sqlite
• r54566: new port php5-mysql
• r54571: new port php5-postgresql
• r54572: new port php5-oracle
• r54573: new port php5-mssql

[ryandesign (Ryan Carsten Schmidt)]

• r55041: updated php5extension to use phpize even for bundled extensions so we can build more of them shared, like the below
• r55043: new port php5-zip
• r55044: new port php5-sockets

[ryandesign (Ryan Carsten Schmidt)]

• r55154: new port php5-iconv
• r55155: new port php5-gettext
• r55156: new port php5-calendar
• r55157: new port php5-pcntl
• r55160: new port php5-wddx
• r55162: new port php5-exif
• r55163: new port php5-ftp
• r55165: new port php5-soap
• r55171: new port php5-mbstring
• r55174: new port php5-openssl
• r55176: new port php5-xmlrpc

[ryandesign (Ryan Carsten Schmidt)]

• r56340: new port php5-posix
• r56346: remove the above features from php5
• r56348: remove the above features from php5-devel
• r56347: make php5-readline and php5-zlib stub ports

This concludes round two of refactoring.

[ryandesign (Ryan Carsten Schmidt)]

Third round of refactoring:

• r58581: new port php5-odbc
• r58585: new port php5-dba (see #20056)
• r58587: new port php5-snmp
• r58589: remove the above features from php5

[ryandesign (Ryan Carsten Schmidt)]

• r58830: remove the above features from php5-devel

This concludes round three of refactoring.

[ryandesign (Ryan Carsten Schmidt)]

• #20492: ldap features moved to php5-ldap port

[ryandesign (Ryan Carsten Schmidt)]

• r74765: remove stub variants from php5 and php5-devel; it's been over a year

[ryandesign (Ryan Carsten Schmidt)]

With the new php53 and php54 ports, even the SAPIs are in separate (sub)ports now. This completes the refactoring.