On Mon, 28 Oct 2002, Melvyn Sopacua wrote:
> At 19:01 28-10-2002, Marcus B�rger wrote:
>
> >At 18:33 28.10.2002, Melvyn Sopacua wrote:
> >>At 18:15 28-10-2002, Marcus B�rger wrote:
> >>
> >>> Log:
> >>> fix this tests
> >>> -they did not dl load module in test....
> >>
> >>Yes, exactly as they shouldn't.
> >>
> >>It's been discussed. Why did you revert that?
> >>
> >>The main reason - to repeat it:
> >>./configure --prefix=/previous/install
> >>
> >>dl('foo.so') => foo.so version is previous install, not current!
> >
> >I did so because skipif.inc did so. Maybe we remove that code
> >from both skipif.inc and test.inc now. Feel free to do that.
>
> Ok, then that was a left over.
>
> IMHO we should do a complete overhaul of */tests/* and remove any dl()
> code, or come up with something, that will force the modules/ directory
> on the testkit.
That should be easy by forcing the extensions directory with a hardcoded
ini setting in run-tests.php... (I think :)
> This is again a good reason to setup php.ini-test.
> Windows will then be a problem, which kinda makes the dl() thingy troublesome
> as well.
I've been thinking about that, but I dont like it that much. I still
want the test suite to be run with as much outside influence (in the
form of users' ini settings). That's why I think we should go with the
following scenario:
1. all things that really need to be hardcoded should go to the
run-tests.php script (in that array we have).
2. If some test needs specific tests the settings for that go to the
--INI-- section.
(We already do this AFAIK)
For the execution of the run-tests.php script itself we do it like this:
1. Every hardcoded setting which is possible (implicit_flush for example
:) we set with ini_set()
2. If for some reason the above can not be used for settings (like
safe_mode, open_basedir), we should make a php.ini-test which we load as additional
ini file with all these settings. This .ini file is then used to
override settings in the users' .ini file. We only need to check if
settings in this .ini file actually override the users' normal .ini
settings. (We can load this additional .ini with something we pass in
the "make test" target in configure.
regards,
Derick
--
---------------------------------------------------------------------------
Derick Rethans http://derickrethans.nl/
JDI Media Solutions
--------------[ if you hold a unix shell to your ear, do you hear the c? ]-
--
PHP CVS Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
