# Nifty feature - Thread: https://externals.io/message/31011 - Original archive: https://news-web.php.net/php.internals/31011 - Started by Rasmus Lerdorf on 2007-07-17T18:00:49+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31011 — Rasmus Lerdorf — 2007-07-17T18:00:49+00:00 URL: https://externals.io/message/31011#31011 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 --- ## #31012 — Antony Dovgal — 2007-07-17T18:10:37+00:00 URL: https://externals.io/message/31011#31012 · In reply to: #31011 > 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-xmlreader > > Check './configure --help' for available options > > -Rasmus > -- Wbr, Antony Dovgal --- ## #31013 — Jani Taskinen — 2007-07-17T19:12:34+00:00 URL: https://externals.io/message/31011#31013 · In reply to: #31011 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-xmlreader > > Check './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 --- ## #31014 — Rasmus Lerdorf — 2007-07-17T19:44:46+00:00 URL: https://externals.io/message/31011#31014 · In reply to: #31013 Jani Taskinen wrote: > Rasmus Lerdorf kirjoitti: > > […] > > 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 --- ## #31015 — Gwynne Raskind — 2007-07-17T20:04:02+00:00 URL: https://externals.io/message/31011#31015 · In reply to: #31014 > > […] > 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." --- ## #31017 — Rasmus Lerdorf — 2007-07-17T20:23:05+00:00 URL: https://externals.io/message/31011#31017 · In reply to: #31015 Gwynne Raskind wrote: > > > […] > > *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 --- ## #31018 — Arnold Daniels — 2007-07-17T20:37:36+00:00 URL: https://externals.io/message/31011#31018 · In reply to: #31017 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: > > > […] > > 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 --- ## #31019 — Rasmus Lerdorf — 2007-07-17T20:48:59+00:00 URL: https://externals.io/message/31011#31019 · In reply to: #31018 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 using `pecl update` to > 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 --- ## #31020 — Jani Taskinen — 2007-07-17T20:51:35+00:00 URL: https://externals.io/message/31011#31020 · In reply to: #31014 Rasmus Lerdorf kirjoitti: > Jani Taskinen wrote: > > […] > > 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 --- ## #31021 — Richard Lynch — 2007-07-17T20:55:10+00:00 URL: https://externals.io/message/31011#31021 · In reply to: #31015 > > […] 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? --- ## #31023 — Jani Taskinen — 2007-07-17T21:03:17+00:00 URL: https://externals.io/message/31011#31023 · In reply to: #31021 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 --- ## #31025 — Arnold Daniels — 2007-07-17T21:12:58+00:00 URL: https://externals.io/message/31011#31025 · In reply to: #31019 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: > > > […] > > 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 --- ## #31027 — Jani Taskinen — 2007-07-17T21:31:34+00:00 URL: https://externals.io/message/31011#31027 · In reply to: #31025 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 --- ## #31029 — Richard Lynch — 2007-07-17T21:45:50+00:00 URL: https://externals.io/message/31011#31029 · In reply to: #31023 > > […] > > 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 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? --- ## #31031 — Jani Taskinen — 2007-07-17T21:53:45+00:00 URL: https://externals.io/message/31011#31031 · In reply to: #31029 Richard Lynch kirjoitti: > > […] > > 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