Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » make test flag? »

make test flag?

php.internals

Brian Shire

19 years ago
I noticed the make test command may need the "-n" flag added so that it will exclude already installed ini files. Specifically this causes a problem when running make test on a system that already has the same DSO installed so it tries to load it twice (once via the installed ini and again for the test). Perhaps there's other places where this causes problems? ... " -n No php.ini file will be used" diff --git a/Makefile.global b/Makefile.global index ec86927..237c1a6 100644 --- a/Makefile.global +++ b/Makefile.global @@ -74,7 +74,7 @@ test: all TEST_PHP_EXECUTABLE=$(PHP_EXECUTABLE) \ TEST_PHP_SRCDIR=$(top_srcdir) \ CC="$(CC)" \ - $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$ $dlname)` tests/; \ + $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php -n -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$$dlname)` tests/; \ elif test ! -z "$(SAPI_CLI_PATH)" && test -x "$(SAPI_CLI_PATH)"; then \ TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \ TEST_PHP_SRCDIR=$(top_srcdir) \ -Brian Shire shire@facebook.com shire@php.net aim: int80h

Marcus Börger

19 years ago
Hello Brian, therun-tests.php command will take care of any INI settings that are known to break tests.So if anyof your INI settings cause tests to failwe simply need to include them into the tests. Othewise it is important to test with your INI settings asyou want to know if your PHP installation works. Instead of knowing whether PHP in general could work. best regards marcus Friday, December 1, 2006, 3:25:15 AM, you wrote:
> I noticed the make test command may need the "-n" flag added so that > it will exclude already installed ini files. Specifically this > causes a problem when running make test on a system that already has > the same DSO installed so it tries to load it twice (once via the > installed ini and again for the test). Perhaps there's other places > where this causes problems? ...
> " -n No php.ini file will be used"
> diff --git a/Makefile.global b/Makefile.global > index ec86927..237c1a6 100644 > --- a/Makefile.global > +++ b/Makefile.global > @@ -74,7 +74,7 @@ test: all > TEST_PHP_EXECUTABLE=$(PHP_EXECUTABLE) \ > TEST_PHP_SRCDIR=$(top_srcdir) \ > CC="$(CC)" \ > - $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d > 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php > -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$ > $dlname)` tests/; \ > + $(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d > 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php > -n -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo > extension=$$dlname)` tests/; \ > elif test ! -z "$(SAPI_CLI_PATH)" && test -x "$(SAPI_CLI_PATH)"; then \ > TEST_PHP_EXECUTABLE=$(top_builddir)/$(SAPI_CLI_PATH) \ > TEST_PHP_SRCDIR=$(top_srcdir) \
> -Brian Shire > shire@facebook.com > shire@php.net > aim: int80h
Best regards, Marcus

Brian Shire

19 years ago
On Dec 1, 2006, at 12:42 AM, Marcus Boerger wrote:
> Hello Brian, > > therun-tests.php command will take care of any INI settings that > are known > to break tests.So if anyof your INI settings cause tests to failwe > simply > need to include them into the tests. Othewise it is important to > test with > your INI settings asyou want to know if your PHP installation > works. Instead > of knowing whether PHP in general could work. >
Thanks Marcus, The actual situation I'm thinking of is when you are running make test on an extension being built as a DSO that is already configured to load in an ini file. When make test is ran it will attempt to load the DSO twice, and gives: "PHP Warning: Module 'apc' already loaded in Unknown on line 0". I thought the preference would be to ignore installed ini files, but if that's not the intention, then my proposed patch of course is bad. -Brian Shire shire@facebook.com shire@php.net aim: int80h

Marcus Börger

19 years ago
Hello Brian, why should it do that? run-tests.php doesn't do anything with extensions. Meaning it only tests when you load your .so's by ini. best regards marcus Saturday, December 2, 2006, 12:16:45 AM, you wrote:
> On Dec 1, 2006, at 12:42 AM, Marcus Boerger wrote:
>> Hello Brian, >> >> therun-tests.php command will take care of any INI settings that >> are known >> to break tests.So if anyof your INI settings cause tests to failwe >> simply >> need to include them into the tests. Othewise it is important to >> test with >> your INI settings asyou want to know if your PHP installation >> works. Instead >> of knowing whether PHP in general could work. >>
> Thanks Marcus,
> The actual situation I'm thinking of is when you are running make > test on an extension being built as a DSO that is already configured > to load in an ini file. When make test is ran it will attempt to > load the DSO twice, and gives: "PHP Warning: Module 'apc' already > loaded in Unknown on line 0".
> I thought the preference would be to ignore installed ini files, but > if that's not the intention, then my proposed patch of course is bad.
> -Brian Shire > shire@facebook.com > shire@php.net > aim: int80h
Best regards, Marcus

Brian Shire

19 years ago
On Dec 1, 2006, at 3:21 PM, Marcus Boerger wrote:
> Hello Brian, > > why should it do that? run-tests.php doesn't do anything with > extensions. > Meaning it only tests when you load your .so's by ini. >
$(PHP_EXECUTABLE) -d 'open_basedir=' -d 'safe_mode=0' -d 'output_buffering=0' -d 'memory_limit=-1' $(top_srcdir)/run-tests.php -d 'extension_dir=modules/' -d `( . $(PHP_MODULES) ; echo extension=$ $dlname)` tests/; \ Given this only affects a make test being done in an extension that has been setup with a "phpize" command. Let me know if I've overlooked anything. I believe the above line that executes the "make test" causes two minor problems for ini files loading DSO's. First it sets the "extension_dir" to modules. Any attempt to load modules from installed ini files will fail because the path is now different. The second is that the last portion loads the extension by doing a "-d extension=<extname>" on the php commandline, which I causes my "already loaded error".
> best regards > marcus > > Saturday, December 2, 2006, 12:16:45 AM, you wrote: > >> On Dec 1, 2006, at 12:42 AM, Marcus Boerger wrote: > >>> Hello Brian, >>> >>> therun-tests.php command will take care of any INI settings that >>> are known >>> to break tests.So if anyof your INI settings cause tests to failwe >>> simply >>> need to include them into the tests. Othewise it is important to >>> test with >>> your INI settings asyou want to know if your PHP installation >>> works. Instead >>> of knowing whether PHP in general could work. >>> > >> Thanks Marcus, > >> The actual situation I'm thinking of is when you are running make >> test on an extension being built as a DSO that is already configured >> to load in an ini file. When make test is ran it will attempt to >> load the DSO twice, and gives: "PHP Warning: Module 'apc' already >> loaded in Unknown on line 0". > >> I thought the preference would be to ignore installed ini files, but >> if that's not the intention, then my proposed patch of course is bad. > > >> -Brian Shire >> shire@facebook.com >> shire@php.net >> aim: int80h > > > > > Best regards, > Marcus >
-Brian Shire shire@facebook.com shire@php.net aim: int80h

Ilia A.

19 years ago
On 1-Dec-06, at 6:21 PM, Marcus Boerger wrote:
> Hello Brian, > > why should it do that? run-tests.php doesn't do anything with > extensions. > Meaning it only tests when you load your .so's by ini.
You can't really tell PHP to "unload" modules via an INI settings, so I think adding -n in there is a pretty good idea. Ilia Alshanetsky

Luca Longinotti

19 years ago
Ilia Alshanetsky wrote:
> On 1-Dec-06, at 6:21 PM, Marcus Boerger wrote: > >> Hello Brian, >> >> why should it do that? run-tests.php doesn't do anything with >> extensions. >> Meaning it only tests when you load your .so's by ini. > > You can't really tell PHP to "unload" modules via an INI settings, so I > think adding -n in there is a pretty good idea.
It is, in fact we already do it in Gentoos PHP, to avoid already installed extensions interfering with the main PHP packages "make test" (on reinstalls or upgrades for example). Here are the patches I've made for this: PHP 5.2.0 http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.0/php5/php5-make_test.patch PHP 5.1.6 http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.1.6/php5/php5-make_test.patch PHP 4.4.4 http://overlays.gentoo.org/proj/php/browser/patches/php-patches/4.4.4/php4/php4-make_test.patch You're probably not interested in the changes to the Makefiles and the CGI/PHP4 testing changes I've done to meet Gentoos requirements, so just skip those.
-- Best regards, Luca Longinotti aka CHTEKK LongiTEKK Networks Admin: chtekk@longitekk.com Gentoo Dev: chtekk@gentoo.org SysCP Dev: chtekk@syscp.org TILUG Supporter: chtekk@tilug.ch

Marcus Börger

19 years ago
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. 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) :-) best regards marcus Saturday, December 2, 2006, 10:15:11 PM, you wrote:
> Ilia Alshanetsky wrote: >> On 1-Dec-06, at 6:21 PM, Marcus Boerger wrote: >> >>> Hello Brian, >>> >>> why should it do that? run-tests.php doesn't do anything with >>> extensions. >>> Meaning it only tests when you load your .so's by ini. >> >> You can't really tell PHP to "unload" modules via an INI settings, so I >> think adding -n in there is a pretty good idea.
> It is, in fact we already do it in Gentoos PHP, to avoid already > installed extensions interfering with the main PHP packages "make test" > (on reinstalls or upgrades for example). > Here are the patches I've made for this:
> PHP 5.2.0 > http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.0/php5/php5-make_test.patch > PHP 5.1.6 > http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.1.6/php5/php5-make_test.patch > PHP 4.4.4 > http://overlays.gentoo.org/proj/php/browser/patches/php-patches/4.4.4/php4/php4-make_test.patch
> You're probably not interested in the changes to the Makefiles and the > CGI/PHP4 testing changes I've done to meet Gentoos requirements, so just > skip those.
Best regards, Marcus

Brian Shire

19 years ago
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.
> 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? Thanks, -Brian Shire shire@facebook.com shire@php.net aim: int80h

Marcus Börger

19 years ago
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 > shire@facebook.com > shire@php.net > aim: int80h
Best regards, Marcus