* Red Wingate <[EMAIL PROTECTED]> [2004-04-16 10:46:19 +0200]:

<snip>
> [quote]
> The CLI SAPI was released for the first time with PHP 4.2.0, but was still 
> experimental and had to be explicitly enabled with --enable-cli when 
> running ./configure. Since PHP 4.3.0 the CLI SAPI is no longer experimental 
> and the option --enable-cli is on by default. You may use --disable-cli to 
> disable it.
> [/quote]
> 
> Using:  './configure --enable-cli --with-mysql' is just right :-)

BTW: the whole bunch of build options is very misleading and inconsistent.

i.e. "foo-support" doesn't say anything, what it really does. 
does it leave space for "foo" to operate ? 
or does it use "foo" to do something magically ? 
or does it automatically make donation to the "foo" project on each request ?
or provide a PHP/Zend binding to foo's API ?


Why cant we at least group several features together and introduce 
a clear naming scheme ? I'd suggest a kind of hierachical namespace.

On some short I've got there different groups in mind:

+ SAPIs to build (even it may sound a little bit misleading,  
  the CLI/standalone interpreter) is also an SAPI.
  perhaps we should someday find a better word, i.e. "interpreter" ?
      
  so their options would be: --enable-sapi-<sapi_name>
  or w/ optional paramter: --enable-sapi-<sapi_name>=<param>

  other sapi-dependend parameters should then be named in the way:
  --sapi-<sapi_name>-<param_name>
  
+ there are many extensions, which all provide a set of functions.
  so their should all be called:
  
  --enable-ext-<ext_name> or --enable-ext-<ext_name>=<data>
  
  It should be made clear, that extensions are _optional_ modules
  (in fact they may exists as .so's)

  Built-in extensions (i.e. pcre) should also be selectable here,
  but of course may be enabled by default.
  
+ many extensions and other features have external dependencies,
  some of these are supplied by bundled libraries.
  
  we should have a way to choose, where to get a library from
  (system wide, some other path or bundled) and whether to do 
  static or dynamic linking. for cross-compiling its also necessary
  to specify a prefix where the stuff at build-time comes from
  (i.e. the root dir of the other target system)
  
  I'd suggest the scheme:
  
  --with-<libname>-source=(bundled|system|/path/to/prefix)      
    --> prefix (FHS-style)
  --with-<libname>-include=/path/to/includes            
    --> include directory (added include search path for importing modules)
  --with-<libname>-static=/path/to/static/lib
  --with-<libname>-dll=/path/to/dynamic/lib
  --with-<libname>-rpath=/pat/to/dll/runtime/path
    --> analogous.
  --with-<libname>-config=/path/to/pkgconfig-script 
    --> path to config script
  --with-<libname>-pkg-config
    --> use freedesktop.org's pkg-config to detect the package.
        (optional parameter is the path to pkg-config)


One big problem with the configure script is its magic autodetection,
which sometimes does stupid things, i.e. enabling some features/extensions
just because it finds a dependency and leaving out because it doesn't
find one of the dependencies and changing this behavour on some 
features from version to version. 
(okay, this is a common autoconf problem - in fact is a fundamental 
design flaw of autoconf)

At least it should produce a really clear and machine readable 
(means regular grammer) output of all available features and modules, 
whether they're enabled (and why) their dependencies, and the used pathes 
and build options/variants.

For example:

[TARGET sapi/cli]
module:                 sapi/cli
install-bindir:         /usr/bin

[MODULE ext/pgsql]
module:                 ext/pgsql
version:                1.2.3.4
description:            postgresql client library binding
enabled:                yes
link-type:              static
depdends:               pg-client>=7.3.0

[DEPEND pg-client]
abi-version:            7.4.1.0
link-type:              dynamic
link-rpath:             /usr/lib/pgsql/lib/

...


Such information is probably not very useful for people just compiling
php on the target system by hand, but its really important to make the
packager's/distributor's live much, much easier.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     [EMAIL PROTECTED]
  cellphone: +49 174 7066481
---------------------------------------------------------------------
   -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting --
---------------------------------------------------------------------

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to