RE: [PHP-DEV] useless config.w32.h and solutions
| From: | Preston L. Bannister | Date: | Mon, 02 Dec 2002 06:46:58 +0000 |
| Subject: | RE: [PHP-DEV] useless config.w32.h and solutions | ||
| References: | 1 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-92002@lists.php.net to get a copy of this message | ||
There is an impedence mismatch here between typical usage on Unix and
typical usage on Windows. Some infomation that can typically be compiled-in
on Unix must be determined at runtime on Windows.
I don't believe the environment is really a good place to be expecting this
information - not on Windows. You run into trouble with differing
applications (bundling PHP) needing to use differing values. If any of this
is run from a service context - it's just not going to work out well.
There is a logical approach to deriving most or all this information on
Windows that works out a bit more cleanly.
Lets start from the beginning.
PHP_BINDIR "c:\\php4"
PEAR_INSTALLDIR "c:\\php4\\pear"
PHP_CONFIG_FILE_PATH ""
PHP_CONFIG_FILE_SCAN_DIR ""
PHP_DATADIR "c:\\php4"
PHP_EXTENSION_DIR "c:\\php4"
PHP_INCLUDE_PATH ".;c:\\php4\\pear"
PHP_LIBDIR "c:\\php4"
PHP_LOCALSTATEDIR "c:\\php4"
PHP_PREFIX "c:\\php4"
PHP_SYSCONFDIR "c:\\php4"
PHP_BINDIR can be exactly determined at runtime (using GetModuleHandle() and
GetModuleFileName() - I can supply the idiom and bewares).
Once you know where PHP was installed, you can assume by default the other
directories as relative. So you have:
PHP_DATADIR %PHP_BINDIR%
PHP_EXTENSION_DIR %PHP_BINDIR%
PHP_INCLUDE_PATH ".;%PHP_BINDIR%"
PHP_LIBDIR %PHP_BINDIR%
PHP_LOCALSTATEDIR %PHP_BINDIR%
PHP_PREFIX %PHP_BINDIR%
PHP_SYSCONFDIR %PHP_BINDIR%
PEAR_INSTALLDIR "%PHP_BINDIR%\\pear"
Since these are all computed values, it would be a good idea to eliminate
the compile-time constants. Better to not pretend - as this will help you
find code that might be a problem.
Finally you go looking for a configuration file to override the defaults.
If the configuration file was not specified on the command line, then you
pick it up from (usually) the installation directory.
( Microsoft sells the idea of using the registry at this point, but in
practice I've found it better to make only minimal use of the registry ).
What I had not figured out last I had time to look at the code, was how to
plug in computed values as though they were compiled in.
-----Original Message-----
From: Frank M. Kromann [mailto:frank@kromann.info]
Sent: Sunday, December 01, 2002 11:55 AM
Yu are right. Two of the values needs to be constants, as these are used
in building the INI array.
Setting the constants to this works:
#define PEAR_INSTALLDIR
(getenv("PEAR_INSTALLDIR"))?getenv("PEAR_INSTALLDIR"):"c:\\php4\\pear"
#define PHP_BINDIR
(getenv("PHP_BINDIR"))?getenv("PHP_BINDIR"):"c:\\php4"
#define PHP_CONFIG_FILE_PATH
(getenv("PHP_CONFIG_FILE_PATH"))?getenv("PHP_CONFIG_FILE_PATH"):""
#define PHP_CONFIG_FILE_SCAN_DIR
(getenv("PHP_CONFIG_FILE_SCAN_DIR"))?getenv("PHP_CONFIG_FILE_SCAN_DIR"):""
#define PHP_DATADIR
(getenv("PHP_DATADIR"))?getenv("PHP_DATADIR"):"c:\\php4"
#define PHP_EXTENSION_DIR "c:\\php4"
#define PHP_INCLUDE_PATH ".;c:\\php4\\pear"
#define PHP_LIBDIR
(getenv("PHP_LIBDIR"))?getenv("PHP_LIBDIR"):"c:\\php4"
#define PHP_LOCALSTATEDIR
(getenv("PHP_LOCALSTATEDIR"))?getenv("PHP_LOCALSTATEDIR"):"c:\\php4"
#define PHP_PREFIX
(getenv("PHP_PREFIX"))?getenv("PHP_PREFIX"):"c:\\php4"
#define PHP_SYSCONFDIR
(getenv("PHP_SYSCONFDIR"))?getenv("PHP_SYSCONFDIR"):"c:\\php4"
PHP_EXTENSION_DIR and PHP_INCLUDE_PATH can both be specified in php.ini
and perhaps we can find a way to set them by environment variables ?
- Frank
> On Sun, 01 Dec 2002 07:57:18 -0800
> "Frank M. Kromann" <frank@kromann.info> wrote:
>
> > We could change it to something like this:
> >
> > #define PEAR_INSTALLDIR
> >
(getenv("PEAR_INSTALLDIR"))?getenv("PEAR_INSTALLDIR"):"c:\\php4\\pear"
>
> As far as I remember, that s what has been done weeks ago and causes a
> compile error. Can you test it on a win32 build ? I should do it later
> tonight or tomorrow.