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
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
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
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:
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
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
marcusSaturday, December 2, 2006, 12:16:45 AM, you 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: int80hBest regards,
Marcus
-Brian Shire
shire@facebook.com
shire@php.net
aim: int80h
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
Ilia Alshanetsky 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
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:
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
Hello Marcus,
Hello Luca,
we cannot do that. This patchwould prevent loading of any shared
extension. And we decided against usingdl()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
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,
Hello Luca,
we cannot do that. This patchwould prevent loading of any shared
extension. And we decided against usingdl()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