Hello Brian, I am not yet convinced we need to do anything. If one wants to execute non default test environment then one can simply use the environment variables and be done. It sounds pretty much as that is a problem of people writing deployment scripts. Actualyl the problem seems to be finding the documentation. And that has been addressed by Ligaya and myself lately. Though I do not know if it has been addressed enough already.
Saturday, December 9, 2006, 9:00:40 PM, you wrote: > Hello Marcus, > On Dec 4, 2006, at 11:37 AM, Marcus Boerger wrote: >> Hello Luca, >> >> we cannot do that. This patchwould prevent loading of any shared >> extension. And we decided against using dl() in the test scripts >> some years >> ago. The only thing we can do here is having a new make thing that >> does pass >> -n to the test script. > Does this mean a patch should be re-worked so that there's a second > type of 'make test' that includes the -n option, that we want to > include the -n in the default 'make test', or that we just need a > different solution completely (or none at all)? Another more > complicated solution that I thought of but didn't explore is to > provide the ability to ignore duplicate extensions for the make > tests. Although this may complicate the php cli for something that > is a pretty specific scenario. The test harness can alsoaddress this issue. It can enforce a certain binary to be tested. But I do not know if that is enough for you. From my perspective the idea was to run the tests from any installed php and then execute all tests by CLI or CGI. And in the sapi/*/tests directories tests would request a certain binary. If there is any issue with that we need to work on that. >> Once again, we test what you will be using, not only >> part of it. If a deployment system hass a problemwith that we need >> tofind >> otehr solutions. In fact we already have anenvironment variable >> today that >> serves the purpose. Simply set TEST_PHP_ARGS=-n and be done (if you >> know >> what it really does) :-) > Didn't realize this existed, would it be preferred to try and have a > DSO extensions set TEST_PHP_ARGS to avoid this situation? If that works for you my initial comment is true. If not I think we should indeed discuss specific test targets. > Thanks, > -Brian Shire > [EMAIL PROTECTED] > [EMAIL PROTECTED] > aim: int80h Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
