Hey Jani, nice job on the unknown configure options check. I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me this:
Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreader
Check './configure --help' for available options
-Rasmus
Hey Jani, nice job on the unknown configure options check.
Yeah, it's really nice.
It also helped me to locate minor error in oci8/config.m4 =)
Thanks, Jani.
I saw the commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
-Rasmus
--
Wbr,
Antony Dovgal
Rasmus Lerdorf kirjoitti:
Hey Jani, nice job on the unknown configure options check. I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
-Rasmus
This is exactly why I added it. :)
Only side-effect is that any 3rd party extension which happens to use the
AC_ARG_* macros will cause it to report those as "unknown". But perhaps it's
time to be update.. ;)
cough APC cough
--Jani
Jani Taskinen wrote:
Rasmus Lerdorf kirjoitti:
Hey Jani, nice job on the unknown configure options check. I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
-Rasmus
This is exactly why I added it. :)
Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I don't
see how this is a problem. The number of people who build pecl
extensions in the main source tree can probably be counted on one hand.
-Rasmus
Hey Jani, nice job on the unknown configure options check. I saw
the
commit go through a couple of days ago, and today it got me to
clean up
an ancient build script I have been using for ages when it gave
me this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
This is exactly why I added it. :)Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I
don't
see how this is a problem. The number of people who build pecl
extensions in the main source tree can probably be counted on one
hand.
raises hand I do... all the time. crawls back under her rock
-- Gwynne, Daughter of the Code
"This whole world is an asylum for the incurable."
Gwynne Raskind wrote:
Hey Jani, nice job on the unknown configure options check. I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me
this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
This is exactly why I added it. :)Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I don't
see how this is a problem. The number of people who build pecl
extensions in the main source tree can probably be counted on one hand.raises hand I do... all the time. crawls back under her rock
Can you explain why? I find it much easier to build the non-core stuff
separately so I can update either without affecting the other.
-Rasmus
Hi Rasmus,
I hope you've got a lot of fingers on your hand, because we do this as well.
All servers are updated with an apt script and our private repository.
It's easier to manage a single php package on all servers, that 14
different packages. Each time PHP updates we take the newest packages
from pecl and sometimes if PHP isn't updated for a more than a month, we
might make a build with the same PHP version but new pecl packages.
To my knowledge this is standard practice for ISP's (who build PHP them
selfs). I haven't heard of anyone actually using pecl update to
update. Most ISP's just update the whole thing one each week, month,
year, decade.
Best regards,
Arnold
Rasmus Lerdorf wrote:
Gwynne Raskind wrote:
Hey Jani, nice job on the unknown configure options check. I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me
this:Notice: Following unknown configure options were used:
--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreaderCheck './configure --help' for available options
This is exactly why I added it. :)
Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I don't
see how this is a problem. The number of people who build pecl
extensions in the main source tree can probably be counted on one hand.raises hand I do... all the time. crawls back under her rock
Can you explain why? I find it much easier to build the non-core stuff
separately so I can update either without affecting the other.-Rasmus
Arnold Daniels wrote:
Hi Rasmus,
I hope you've got a lot of fingers on your hand, because we do this as well.
All servers are updated with an apt script and our private repository.
It's easier to manage a single php package on all servers, that 14
different packages. Each time PHP updates we take the newest packages
from pecl and sometimes if PHP isn't updated for a more than a month, we
might make a build with the same PHP version but new pecl packages.To my knowledge this is standard practice for ISP's (who build PHP them
selfs). I haven't heard of anyone actually usingpecl updateto
update. Most ISP's just update the whole thing one each week, month,
year, decade.
I'm not talking about pecl update. I never use that either. The way we
do it at Yahoo, and the way the distros do it, is to create separate
packages for as many things as possible such that in order to quickly
update any component we can do it with the lowest impact possible. Not
all servers have all the PHP-related packages installed, obviously, so
if there is a critical update to a specific package we can limit it to
just the affected servers.
-Rasmus
Hi,
I understand, but Yahoo is huge. We are not... Saying that it is
standard practice for ISP's is perhaps (ehh for sure) a bit of an
overstatement, since I only have contact with other small hosting
providers like us.
For us making packages actually takes up a significant amount of time,
so creating a different package for everything is simply not feasible.
Also all our web servers have the same configuration (luckily).
Anyway, I only mend to say that building pecl packages in the PHP distro
isn't so rare as just claimed. So it would be nice if this nifty feature
would also work for added packages.
Best regards,
Arnold
Rasmus Lerdorf wrote:
Arnold Daniels wrote:
Hi Rasmus,
I hope you've got a lot of fingers on your hand, because we do this as well.
All servers are updated with an apt script and our private repository.
It's easier to manage a single php package on all servers, that 14
different packages. Each time PHP updates we take the newest packages
from pecl and sometimes if PHP isn't updated for a more than a month, we
might make a build with the same PHP version but new pecl packages.To my knowledge this is standard practice for ISP's (who build PHP them
selfs). I haven't heard of anyone actually usingpecl updateto
update. Most ISP's just update the whole thing one each week, month,
year, decade.I'm not talking about pecl update. I never use that either. The way we
do it at Yahoo, and the way the distros do it, is to create separate
packages for as many things as possible such that in order to quickly
update any component we can do it with the lowest impact possible. Not
all servers have all the PHP-related packages installed, obviously, so
if there is a critical update to a specific package we can limit it to
just the affected servers.-Rasmus
Arnold Daniels kirjoitti:
Anyway, I only mend to say that building pecl packages in the PHP distro
isn't so rare as just claimed. So it would be nice if this nifty feature
would also work for added packages.
It works for everything but phpize'd builds.
If you find out that some extension in pecl uses AC_ARG_*, please let me know
and I'll fix those..
--Jani
Only side-effect is that any 3rd party extension which happens to
use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I
don't
see how this is a problem.
Maybe this check should be in a phpize-generated configure script, so
that new extensions will have it built-in?
MANY bug reports and build issues, especially for newbies, are caused
by a simple typo that this would catch, if I'm understanding what it
does without actually trying it yet...
And, hey, if it helps even the experienced developers do a bit of
clean-up on old build scripts, that's a Good Thing too, imho. :-)
Now if we could just get configure to HALT when an option that is
enabled by default but is specified on the command line as well isn't
available, so users aren't confused by it continuing to build
something they didn't ask for in the first place... :-v
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch kirjoitti:
Maybe this check should be in a phpize-generated configure script, so
that new extensions will have it built-in?
I left it out intentionally from phpize. It is just a notice but I rather not
see any bug reports about 3rd party stuff. :)
MANY bug reports and build issues, especially for newbies, are caused
by a simple typo that this would catch, if I'm understanding what it
does without actually trying it yet...
People still have options like '--enable-track-vars' in use. :)
This feature also works as a notice for removed options, such as the late
--enable-versioning removal.. ;)
And, hey, if it helps even the experienced developers do a bit of
clean-up on old build scripts, that's a Good Thing too, imho. :-)
It already helped me to find a typo in one option..
Now if we could just get configure to HALT when an option that is
enabled by default but is specified on the command line as well isn't
available, so users aren't confused by it continuing to build
something they didn't ask for in the first place... :-v
This didn't compute. Halt on option that is enabled by default but isn't
available?? huh?
--Jani
Now if we could just get configure to HALT when an option that is
enabled by default but is specified on the command line as well
isn't
available, so users aren't confused by it continuing to build
something they didn't ask for in the first place... :-vThis didn't compute. Halt on option that is enabled by default but
isn't
available?? huh?
Joe Sixpack or Betty Buick goes to compile PHP.
They do something not unlike:
./configure --enable-jpeg
Assume --enable-jpeg is "on" by default (or defaults to "on" after you
turn on GD?)
Then assume that JPEG is not actually installed, or can't be found.
AFAICT, because it's on by default in the first place, the fact that
the user asked for it has no effect on the outcome:
configure will cheerfully continue to build a system which has no JPEG.
The user asked for JPEG.
The user gets no JPEG.
And it seems to work, only it doesn't have what they asked for.
It's been a never-ending source of confusion to users who kind of
expect the darn thing to puke on their pretty blue shoes if they ask
for X and it can't find X...
--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?
Richard Lynch kirjoitti:
This didn't compute. Halt on option that is enabled by default but
isn't
available?? huh?Joe Sixpack or Betty Buick goes to compile PHP.
They do something not unlike:
/configure --enable-jpeg
This causes a notice of unknown option now..since that option does not exist. :)
So I guess it's already handled somewhat. Unfortunately anything more needs some
AI to be developed. :)
--Jani
Rasmus Lerdorf kirjoitti:
Jani Taskinen wrote:
Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)cough APC cough
But this check isn't in a phpize-generated configure script, so I don't
see how this is a problem. The number of people who build pecl
extensions in the main source tree can probably be counted on one hand.
I was just thinking when apc is included in core, that's the last minute to
change those options. ;)
Fortunately there weren't many exts in pecl that use the AC_ARG_*..I'll fix
those soonish.
--Jani