Everything

php

Nifty feature

php.internals

Rasmus Lerdorf

19 years ago

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

Antony Dovgal

19 years ago

On 17.07.2007 22:00, Rasmus Lerdorf wrote:

> 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

Jani Taskinen

19 years ago

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

Rasmus Lerdorf

19 years ago

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-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*

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

Gwynne Raskind

19 years ago

On Jul 17, 2007, at 3:44 PM, Rasmus Lerdorf 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-xmlreader
>>>
>>> Check './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."

Rasmus Lerdorf

19 years ago

Gwynne Raskind wrote:

> On Jul 17, 2007, at 3:44 PM, Rasmus Lerdorf 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-xmlreader
>>>>
>>>> Check './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

19 years ago

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:

Rasmus Lerdorf

19 years ago

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

Arnold Daniels

19 years ago

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:

Jani Taskinen

19 years ago

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

Richard Lynch

19 years ago

On Tue, July 17, 2007 3:04 pm, Gwynne Raskind 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.

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?

Jani Taskinen

19 years ago

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

Richard Lynch

19 years ago

On Tue, July 17, 2007 4:03 pm, Jani Taskinen wrote:

>> 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?

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?

Jani Taskinen

19 years ago

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

Jani Taskinen

19 years ago

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