Re: [RFC] include_ini and include_ini_dir

Hi Brian, I haven't looked at your patch in detail (sorry! but see below). I thought that the official view was that php.ini probably shouldn't do anything too clever, even if it is quite a simple matter of implementing these advanced features? My position on the include_ini stuff is -0, meaning that I'm somewhat against the idea because php.ini isn't easy to manage with multiple versions/sapi of PHP (particularly under Windows), and I can see that using includes can make things quite hard to follow (based on my early experience of the apache configuration files, before they became unified!). Personally, I can't think of a situation where include would be useful (based on the kind of things that I do) without some kind of conditional evaluation of the ini file - and that is definitely not desired (check the archives). However, I'm not actively opposed to it making it into PHP if that is the general consensus. > include_ini_dir has to be the full path. I didn't know the best > way to find the directory from the search path like how the > php_fopen_with_path does it (so I just make it work with full paths). > Please tell me how to do this so I can use the search paths and > relative directories names. Assuming that we really want these features, why not borrow the guts of php_fopen_with_path but modify it to use opendir instead of php_fopen_and_set_opened_path? (php_opendir_with_path ?) > Yes, it is based off of the 4.2.3 release, but I am looking for > more input on fixing current problems then getting into the next > release. Arrgh! You should *really* be working against HEAD because there have been so many changes since we branched 4.2 - and some of those were related to php.ini detection. It's a LOT easier to deal with patches against HEAD (take a look in README.SUBMITTING_PATCH), as most of php-dev have HEAD ready-to-hack; not all of us have the 4.2 branch handy, and our policy is not to add new features to it. --Wez.