Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Flávio Heleno]

On Thu, Dec 9, 2021, 18:56 Christoph M. Becker  wrote:

> On 09.12.2021 at 20:59, Flávio Heleno wrote:
>
> > On Thu, Dec 9, 2021 at 4:46 PM Nikita Popov 
> wrote:
> >
> >> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
> >> wrote:
> >>
> >>> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
> >>>
>  Earlier this year, I added support for AVIF images
>   to libgd
>  . My ultimate goal was to bring
> >> support
> >>> for
>  this new image format to PHP, so that the world's top CMSs could let
> >>> sites
>  serve AVIFs. A few of you kindly guided me as I made my first
> >>> contributions
>  to the PHP codebase, propagating libgd's new AVIF support
>   into PHP's bundled gd
> fork,
>  and adding
>  AVIF awareness  to non-gd
>  functions like getimagesize() and imagecreatefromstring().
> 
>  Unfortunately, when I worked on getimagesize(), AVIF experts advised
> >> that
>  there was no compact, reliable way to determine the size of an AVIF
> >> image
>  without relying on an external library like libavif. We decided
>  
> that
> >>> it
>  was useful to return the information that a given image was an AVIF,
> >> but
>  simply to return 0 for the actual dimensions and other details. The
> >> user
>  would simply need to decode the image to determine this information.
> 
>  Of course, users would really like
>   to
> >> use
>  getimagesize() to return the actual size. So a colleague has kindly
>  created standalone
>  code 
> >>> (that
>  doesn't depend on libavif) to do this, with the goal of adding it to
> >> PHP.
> 
>  The code comprises several hundred lines. But - it works, and it works
> >>> well.
> 
>  Would it be ok to submit a PR containing this code to add this
>  functionality? Or does someone have a superior approach?
> >>>
> >>> Thanks for your and your colleague's work!  It's highly appreciated.
> >>>
> >>> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> >>> bundling libavifinfo.  I'm not too concerned regarding the additional
> >>> size of the PHP binaries which would result by linking it in, but if
> >>> others are, we could still introduce a configuration option (e.g.
> >>> `--with-libavifinfo`).
> >>>
> >>> Thoughts?  Objections to bundling libavifinfo at all?
> >>>
> >>> [1] 
> >>>
> >>
> >> Assuming no licensing concerns, bundling libavifinfo sounds reasonable.
> The
> >> library is small, our avif functionality is incomplete without it, and
> we
> >> can't expect this to be available as a system library at this time.
> >> Although I'm not a core contributor, my 2c is that even with libavifinfo
> > bundled, a configuration option is
> > very welcome, the same way we have for png, jpeg, xpm and webp.
>
> Whether AVIF support should be included for ext/gd is already
> configurable.  This is solely about the getimagesize(fromstring) and
> image_type_to_* functions which are part of ext/std.  We do not have
> configuration options for these for the other image formats either.
>
> --
> Christoph M. Becker
>

Got it! I was refering to the general avif support, glad to see that it's
already there =)

>

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Ahhh okay that explains where this change is coming from. Thanks a lot, Dan!

I wonder if this side effect ("all dependencies are iterated also
during "make install") is intentional.

Maybe Niki can chime in on GitHub; I'll ping him there, as well as the
original author.

Thanks a lot!

David

P.S. regarding your earlier comment on the '-include' directive - that
allows the actual file you're specifying there to be missing; not any
file names listed inside it - the purpose is to optionally let
generic/templated Makefiles specify a file that lists additional
includes, but making that file itself optional.

On Thu, Dec 9, 2021 at 8:41 PM Dan Ackroyd  wrote:
>
> On Thu, 9 Dec 2021 at 19:28, Dan Ackroyd  wrote:
> > >  Is this intentional? If so, could someone explain the purpose of the 
> > > change?
> >
> > Probably to make the build process less flaky, by explicitly checking
> > dependencies, so that there are fewer instances of "stuffs not
> > working.I guess I'll do a make clean and see if that helps".
> >
>
> And of course I find the commit just after sending previous email:
>
> commit - 
> https://github.com/php/php-src/commit/c4d508c2bc09860bfa15b7f520e0ba68425acfc1
> reasoning - https://github.com/php/php-src/pull/6693
>
> cheers
> Dan
> Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Thanks for your response! I'm not removing PHP before *compiling*, I
am removing it before *installing*:

1) download/extract PHP (as a build dependency) to $PREFIX
2) phpize
3) ./configure --prefix=$PREFIX
4) make
5) remove PHP from $PREFIX
6) make install

The purpose is to have a clean $PREFIX directory that, in its
entirety, can be compressed into an archive for distribution of only
that extension's files.

Does that make sense?

On Thu, Dec 9, 2021 at 8:28 PM Dan Ackroyd  wrote:
>
> On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals
>  wrote:
> >
> > That doesn't work with PHP 8.1 anymore - the Makefile generated by
> > phpize now contains an include directive at the top level (near the
> > bottom), e.g.:
> >
> > -include src/php_raphf_api.dep
>
> The file src/php_raphf_api.dep is created when the source code is
> compiled. It creates a list of which files were used in the
> compilation of a C file. In this case src/php_raphf_api.c
>
> The '-include' directive apparently allows for a file to be listed,
> but not error when it doesn't exist, apparently:
> https://www.gnu.org/software/make/manual/html_node/Features.html so on
> a fresh cleaned build, it shouldn't make any difference.
>
> > Which lists not only the extension's headers, but also all of PHP's
> > (in include/main, include/Zend, and so forth):
>
> Yes. Those are the files that need to be present to compile that
> source code file. It's used to check to see if a C file should be
> recompiled, as one of it's dependencies has changed. The dep file is
> also deleted when doing make clean.
>
> It doesn't appear to me that the change to the phpize and the dep file
> is affecting other peopleI think the problem you're seeing is
> something unique to your build process. In particular:
>
> 1. Are you doing a make clean, or is there a chance of left over files
> from a previous build?
>
> 2. Why are you (as far as I understand) deleting the PHP files in `5)
> rm -rf $installdir`, before compiling the extension? The command `make
> install` does a check on whether anything needs recompiling.and I
> believe it's failing because the files it's trying to check no longer
> exist.
>
> >  Is this intentional? If so, could someone explain the purpose of the 
> > change?
>
> Probably to make the build process less flaky, by explicitly checking
> dependencies, so that there are fewer instances of "stuffs not
> working.I guess I'll do a make clean and see if that helps".
>
> cheers
> Dan
> Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Christoph M. Becker]

On 09.12.2021 at 20:59, Flávio Heleno wrote:

> On Thu, Dec 9, 2021 at 4:46 PM Nikita Popov  wrote:
>
>> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
>> wrote:
>>
>>> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>>>
 Earlier this year, I added support for AVIF images
  to libgd
 . My ultimate goal was to bring
>> support
>>> for
 this new image format to PHP, so that the world's top CMSs could let
>>> sites
 serve AVIFs. A few of you kindly guided me as I made my first
>>> contributions
 to the PHP codebase, propagating libgd's new AVIF support
  into PHP's bundled gd fork,
 and adding
 AVIF awareness  to non-gd
 functions like getimagesize() and imagecreatefromstring().

 Unfortunately, when I worked on getimagesize(), AVIF experts advised
>> that
 there was no compact, reliable way to determine the size of an AVIF
>> image
 without relying on an external library like libavif. We decided
  that
>>> it
 was useful to return the information that a given image was an AVIF,
>> but
 simply to return 0 for the actual dimensions and other details. The
>> user
 would simply need to decode the image to determine this information.

 Of course, users would really like
  to
>> use
 getimagesize() to return the actual size. So a colleague has kindly
 created standalone
 code 
>>> (that
 doesn't depend on libavif) to do this, with the goal of adding it to
>> PHP.

 The code comprises several hundred lines. But - it works, and it works
>>> well.

 Would it be ok to submit a PR containing this code to add this
 functionality? Or does someone have a superior approach?
>>>
>>> Thanks for your and your colleague's work!  It's highly appreciated.
>>>
>>> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
>>> bundling libavifinfo.  I'm not too concerned regarding the additional
>>> size of the PHP binaries which would result by linking it in, but if
>>> others are, we could still introduce a configuration option (e.g.
>>> `--with-libavifinfo`).
>>>
>>> Thoughts?  Objections to bundling libavifinfo at all?
>>>
>>> [1] 
>>>
>>
>> Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The
>> library is small, our avif functionality is incomplete without it, and we
>> can't expect this to be available as a system library at this time.
>> Although I'm not a core contributor, my 2c is that even with libavifinfo
> bundled, a configuration option is
> very welcome, the same way we have for png, jpeg, xpm and webp.

Whether AVIF support should be included for ext/gd is already
configurable.  This is solely about the getimagesize(fromstring) and
image_type_to_* functions which are part of ext/std.  We do not have
configuration options for these for the other image formats either.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Ben Morss via internals]

Thanks for the discussion, everyone!

Fortunately there are no licensing concerns, as the author is making this
code available to be copied and pasted freely. And we've already got the
build flag for avif.

I'll be excited to see getimagesize() actually return the size for AVIF
images ☺️


On Thu, Dec 9, 2021 at 2:45 PM Nikita Popov  wrote:

> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
> wrote:
>
>> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>>
>> > Earlier this year, I added support for AVIF images
>> >  to libgd
>> > . My ultimate goal was to bring
>> support for
>> > this new image format to PHP, so that the world's top CMSs could let
>> sites
>> > serve AVIFs. A few of you kindly guided me as I made my first
>> contributions
>> > to the PHP codebase, propagating libgd's new AVIF support
>> >  into PHP's bundled gd fork,
>> > and adding
>> > AVIF awareness  to non-gd
>> > functions like getimagesize() and imagecreatefromstring().
>> >
>> > Unfortunately, when I worked on getimagesize(), AVIF experts advised
>> that
>> > there was no compact, reliable way to determine the size of an AVIF
>> image
>> > without relying on an external library like libavif. We decided
>> >  that
>> it
>> > was useful to return the information that a given image was an AVIF, but
>> > simply to return 0 for the actual dimensions and other details. The user
>> > would simply need to decode the image to determine this information.
>> >
>> > Of course, users would really like
>> >  to
>> use
>> > getimagesize() to return the actual size. So a colleague has kindly
>> > created standalone
>> > code 
>> (that
>> > doesn't depend on libavif) to do this, with the goal of adding it to
>> PHP.
>> >
>> > The code comprises several hundred lines. But - it works, and it works
>> well.
>> >
>> > Would it be ok to submit a PR containing this code to add this
>> > functionality? Or does someone have a superior approach?
>>
>> Thanks for your and your colleague's work!  It's highly appreciated.
>>
>> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
>> bundling libavifinfo.  I'm not too concerned regarding the additional
>> size of the PHP binaries which would result by linking it in, but if
>> others are, we could still introduce a configuration option (e.g.
>> `--with-libavifinfo`).
>>
>> Thoughts?  Objections to bundling libavifinfo at all?
>>
>> [1] 
>>
>
> Assuming no licensing concerns, bundling libavifinfo sounds reasonable.
> The library is small, our avif functionality is incomplete without it, and
> we can't expect this to be available as a system library at this time.
>
> Regards,
> Nikita
>

[PHP-DEV] Discussion array_get_type()

[Thomas Bley]

Hello,

since there are currently no type declarations for specific arrays (int[], 
string[], MyClass[], etc.), I'd like to ask if it would make sense to have a 
function array_get_type() in php core?
As I'm not a C developer, I can only ask for your help for the implementation. 
I think having it in the core will provide much better performance, esp. when 
the result could get cached on first evaluation (and the cache is invalidated 
when the array is modified).

function array_get_type(array $array): string
{
$result = null;
foreach ($array as $elem) {
$type = get_debug_type($elem);
$result ??= $type;
if ($type != $result) {
return 'mixed';
}
}

return $result ?? '';
}

echo array_get_type([1,2,3]), PHP_EOL; // int
echo array_get_type([0.1, 0.2]), PHP_EOL; // float
echo array_get_type(['a','b']), PHP_EOL; // string
echo array_get_type([true,false]), PHP_EOL; // bool
echo array_get_type([null,null]), PHP_EOL; // null
echo array_get_type([]), PHP_EOL; // ''
echo array_get_type([new stdClass, new stdClass]), PHP_EOL; // 'stdClass'
echo array_get_type(['a',null]), PHP_EOL; // mixed
echo array_get_type([1,0.2]), PHP_EOL; // mixed
echo array_get_type([new class {},new class {}]), PHP_EOL; // class@anonymous
echo array_get_type([function() {},function() {}]), PHP_EOL; // Closure
echo array_get_type([new DateTime(), new DateTime()]), PHP_EOL; // DateTime
echo array_get_type([new DateTime(), new DateTimeImmutable()]), PHP_EOL; // 
mixed

Having this function would make it easier to check types of arrays and avoid 
things like array_sum([1, 'a', 'b', 2]);

Best Regards
Thomas

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allow default parameters before non-default ones?

[Rowan Tommins]

On 09/12/2021 21:07, Rowan Tommins wrote:
For some reason, the CI build failed on that PR, but on unrelated 
files, so I'm not sure if it's my fault or not. 



Ah no, it was me. Build passing now.


--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allow default parameters before non-default ones?

[Rowan Tommins]

On 09/12/2021 12:45, Christoph M. Becker wrote:

The new behavior has been introduced[1] quite a while after this mail
had been sent.  I agree with the idea outlined in the commit message.

I suggest to document that in the migration guide, and in the manual proper.



Good spot. I guess it does make sense to treat this as an accident in 
8.0, rather than a feature that was added and then immediately removed.


I've raised a PR to add this to the Migration Guide, and update the 
general description of optional parameters: 
https://github.com/php/doc-en/pull/1191


For some reason, the CI build failed on that PR, but on unrelated files, 
so I'm not sure if it's my fault or not.


Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Jordan LeDoux]

Hello internals,

I last brought this RFC up for discussion in August, and there was
certainly interesting discussion. Since then there have been many
improvements, and I'd like to re-open discussion on this RFC. I mentioned
in the first email to the list that I was planning on taking a while before
approaching a vote, however the RFC is much closer to vote-ready now, and
I'd like to open discussion with that in mind.

RFC Link: https://wiki.php.net/rfc/user_defined_operator_overloads

There is a patch for this RFC, however the latest commits are not playable.
It will build, but with various problems which are being worked on related
to enums. The last playable commit can be found by checking out this commit:

https://github.com/JordanRL/php-src/commit/e044f53830a9ded19f7c16a9542521601ac3f331

This commit however does not have the enum for operator position described
in the RFC. It uses a bool instead with true being the left side, and false
being the right side.

Implementation details still left:
- There are issues related to opcache/JIT still, so if you want to play
around with the playable commit disable both.
- Reflection has not been updated, but the proposed updates necessary are
described in the RFC.

It is a long RFC, but operator overloads are a complicated topic if done
correctly. Please review the FAQ section before asking a question, as it
covers many of the main objections or inquiries to the feature. I'd be
happy to expand on any of the answers there if prompted however.

Jordan

Re: [PHP-DEV] Automatic implementation of Stringable may conflict with old, untyped arginfo declarations

[Dan Ackroyd]

On Wed, 8 Dec 2021 at 16:02, Jeremy Mikola  wrote:
>
>
> We haven't explored using stubs, but I'll keep that in mind. ...
>  (which we plan to do since we finally dropped support for PHP
> 7.1).
>

FYI, the stub files maintain #ifdef info through their processing,
which allows some useful shenanigans* e.g.:

https://github.com/Imagick/imagick/blob/86d95fed787d60db110ccfeb2d89ec53f1d1f5f7/Imagick.stub.php#L168-L182
https://github.com/Imagick/imagick/blob/86d95fed787d60db110ccfeb2d89ec53f1d1f5f7/Imagick_arginfo.h#L748-L778

So the stubs are used to generate arg info for Imagick from PHP 5.4 to
8.1, across lots of versions of ImagickMagick.

I'm finding managing function signatures in a PHP file, in standard
PHP format, is a lot nicer than maintaing that info in C files.

cheers
Dan
Ack

* Though, tbh, I wished I'd known about /** @generate-legacy-arginfo
*/ before doing some of the hacks in the Imagick regen_arginfo.sh
script.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Flávio Heleno]

On Thu, Dec 9, 2021 at 4:46 PM Nikita Popov  wrote:

> On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
> wrote:
>
> > On 01.12.2021 at 00:52, Ben Morss via internals wrote:
> >
> > > Earlier this year, I added support for AVIF images
> > >  to libgd
> > > . My ultimate goal was to bring
> support
> > for
> > > this new image format to PHP, so that the world's top CMSs could let
> > sites
> > > serve AVIFs. A few of you kindly guided me as I made my first
> > contributions
> > > to the PHP codebase, propagating libgd's new AVIF support
> > >  into PHP's bundled gd fork,
> > > and adding
> > > AVIF awareness  to non-gd
> > > functions like getimagesize() and imagecreatefromstring().
> > >
> > > Unfortunately, when I worked on getimagesize(), AVIF experts advised
> that
> > > there was no compact, reliable way to determine the size of an AVIF
> image
> > > without relying on an external library like libavif. We decided
> > >  that
> > it
> > > was useful to return the information that a given image was an AVIF,
> but
> > > simply to return 0 for the actual dimensions and other details. The
> user
> > > would simply need to decode the image to determine this information.
> > >
> > > Of course, users would really like
> > >  to
> use
> > > getimagesize() to return the actual size. So a colleague has kindly
> > > created standalone
> > > code 
> > (that
> > > doesn't depend on libavif) to do this, with the goal of adding it to
> PHP.
> > >
> > > The code comprises several hundred lines. But - it works, and it works
> > well.
> > >
> > > Would it be ok to submit a PR containing this code to add this
> > > functionality? Or does someone have a superior approach?
> >
> > Thanks for your and your colleague's work!  It's highly appreciated.
> >
> > Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> > bundling libavifinfo.  I'm not too concerned regarding the additional
> > size of the PHP binaries which would result by linking it in, but if
> > others are, we could still introduce a configuration option (e.g.
> > `--with-libavifinfo`).
> >
> > Thoughts?  Objections to bundling libavifinfo at all?
> >
> > [1] 
> >
>
> Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The
> library is small, our avif functionality is incomplete without it, and we
> can't expect this to be available as a system library at this time.
>
> Regards,
> Nikita
>

Although I'm not a core contributor, my 2c is that even with libavifinfo
bundled, a configuration option is
very welcome, the same way we have for png, jpeg, xpm and webp.

As *cmb* said, thanks for your and your colleague's work!

-- 
Atenciosamente,

Flávio Heleno

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Nikita Popov]

On Wed, Dec 8, 2021 at 12:41 PM Christoph M. Becker 
wrote:

> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>
> > Earlier this year, I added support for AVIF images
> >  to libgd
> > . My ultimate goal was to bring support
> for
> > this new image format to PHP, so that the world's top CMSs could let
> sites
> > serve AVIFs. A few of you kindly guided me as I made my first
> contributions
> > to the PHP codebase, propagating libgd's new AVIF support
> >  into PHP's bundled gd fork,
> > and adding
> > AVIF awareness  to non-gd
> > functions like getimagesize() and imagecreatefromstring().
> >
> > Unfortunately, when I worked on getimagesize(), AVIF experts advised that
> > there was no compact, reliable way to determine the size of an AVIF image
> > without relying on an external library like libavif. We decided
> >  that
> it
> > was useful to return the information that a given image was an AVIF, but
> > simply to return 0 for the actual dimensions and other details. The user
> > would simply need to decode the image to determine this information.
> >
> > Of course, users would really like
> >  to use
> > getimagesize() to return the actual size. So a colleague has kindly
> > created standalone
> > code 
> (that
> > doesn't depend on libavif) to do this, with the goal of adding it to PHP.
> >
> > The code comprises several hundred lines. But - it works, and it works
> well.
> >
> > Would it be ok to submit a PR containing this code to add this
> > functionality? Or does someone have a superior approach?
>
> Thanks for your and your colleague's work!  It's highly appreciated.
>
> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> bundling libavifinfo.  I'm not too concerned regarding the additional
> size of the PHP binaries which would result by linking it in, but if
> others are, we could still introduce a configuration option (e.g.
> `--with-libavifinfo`).
>
> Thoughts?  Objections to bundling libavifinfo at all?
>
> [1] 
>

Assuming no licensing concerns, bundling libavifinfo sounds reasonable. The
library is small, our avif functionality is incomplete without it, and we
can't expect this to be available as a system library at this time.

Regards,
Nikita

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Dan Ackroyd]

On Thu, 9 Dec 2021 at 19:28, Dan Ackroyd  wrote:
> >  Is this intentional? If so, could someone explain the purpose of the 
> > change?
>
> Probably to make the build process less flaky, by explicitly checking
> dependencies, so that there are fewer instances of "stuffs not
> working.I guess I'll do a make clean and see if that helps".
>

And of course I find the commit just after sending previous email:

commit - 
https://github.com/php/php-src/commit/c4d508c2bc09860bfa15b7f520e0ba68425acfc1
reasoning - https://github.com/php/php-src/pull/6693

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Dan Ackroyd]

On Wed, 8 Dec 2021 at 15:25, David Zuelke via internals
 wrote:
>
> That doesn't work with PHP 8.1 anymore - the Makefile generated by
> phpize now contains an include directive at the top level (near the
> bottom), e.g.:
>
> -include src/php_raphf_api.dep

The file src/php_raphf_api.dep is created when the source code is
compiled. It creates a list of which files were used in the
compilation of a C file. In this case src/php_raphf_api.c

The '-include' directive apparently allows for a file to be listed,
but not error when it doesn't exist, apparently:
https://www.gnu.org/software/make/manual/html_node/Features.html so on
a fresh cleaned build, it shouldn't make any difference.

> Which lists not only the extension's headers, but also all of PHP's
> (in include/main, include/Zend, and so forth):

Yes. Those are the files that need to be present to compile that
source code file. It's used to check to see if a C file should be
recompiled, as one of it's dependencies has changed. The dep file is
also deleted when doing make clean.

It doesn't appear to me that the change to the phpize and the dep file
is affecting other peopleI think the problem you're seeing is
something unique to your build process. In particular:

1. Are you doing a make clean, or is there a chance of left over files
from a previous build?

2. Why are you (as far as I understand) deleting the PHP files in `5)
rm -rf $installdir`, before compiling the extension? The command `make
install` does a check on whether anything needs recompiling.and I
believe it's failing because the files it's trying to check no longer
exist.

>  Is this intentional? If so, could someone explain the purpose of the change?

Probably to make the build process less flaky, by explicitly checking
dependencies, so that there are fewer instances of "stuffs not
working.I guess I'll do a make clean and see if that helps".

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

See my previous messages; there's step by step output where I trigger
it with your extension by renaming the directory containing the PHP
it's built against (this obviously requires you have a PHP that's
built with --prefix=/usr/local/myphpbuild or whatever).

I suppose the solution for now is to use 'make
INSTALL_ROOT=/tmp/mypackagedir install', but that's a PHP specific
thing; other software, like Nginx for example, uses the more
"standard" DESTDIR variable as recommended by
https://www.gnu.org/prep/standards/html_node/DESTDIR.html for staged
installs.

That's why I am asking here for the reason this change was made. If
it's unintentional, then it should be fixable; if it's on purpose,
then maybe migrating PHP's Makefiles to also use DESTDIR would be
useful in order to allow generic build tooling to have fewer special
cases for PHP.

David


On Thu, Dec 9, 2021 at 6:14 PM Glash Gnome  wrote:
>
> Right.
> > configure && make && make install
> works.
>
> For my personal information : Now which command should I use to get the error 
> ?
>
>
> Le jeu. 9 déc. 2021 à 17:34, David Zuelke  a écrit :
>>
>> Of course a 'make && make install' works. That is *not* what's broken
>> since 8.1, and not what I'm talking about.
>>
>>
>> On Thu, Dec 9, 2021 at 4:53 PM Glash Gnome  wrote:
>> >
>> > Thanks a lot.
>> > I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
>> > And I can't reproduce the error with my build procedure.
>> > But, if I use "make -d install' insteadof "make && make install' I get 
>> > errors.
>> >
>> > Can you confirm it ?
>> >
>> >
>> >
>> >
>> >
>> > Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a écrit 
>> > :
>> >>
>> >> Yes, of course; it happens with any extension, because the Makefile
>> >> generated by 8.1's 'phpize' now lists those header dependencies even
>> >> for 'make install'.
>> >>
>> >> Like I described, you can reproduce this by 'make'ing the extension,
>> >> then moving the PHP you used to build the extension, then running
>> >> 'make install' (sample with your ext, on my build environment for
>> >> Heroku's PHP support):
>> >>
>> >> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
>> >> root@8f6813d6dc88:/app# which php
>> >> /app/.heroku/php/bin/php
>> >> root@8f6813d6dc88:/app# php -v
>> >> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
>> >> Copyright (c) The PHP Group
>> >> Zend Engine v4.1.0, Copyright (c) Zend Technologies
>> >> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
>> >>
>> >> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
>> >> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
>> >> https://github.com/gtkphp/php-ext-cairo-src
>> >> Cloning into 'php-ext-cairo-src'...
>> >> …
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
>> >> origin/PHP-8.0
>> >> Note: checking out 'origin/PHP-8.0'.
>> >>
>> >> You are in 'detached HEAD' state. You can look around, make experimental
>> >> …
>> >>
>> >> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
>> >> Configuring for:
>> >> PHP Api Version: 20210902
>> >> Zend Module Api No:  20210902
>> >> Zend Extension Api No:   420210902
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
>> >> --prefix=/app/.heroku/php
>> >> …
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
>> >> …
>> >> Build complete.
>> >> Don't forget to run 'make test'.
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
>> >> /app/.heroku/php{,_}
>> >>
>> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
>> >> make: *** No rule to make target
>> >> '/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
>> >> Stop.
>> >>
>> >>
>> >> On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
>> >> >
>> >> > Thanks, I'll check it out.
>> >> >
>> >> > I'm confused. Can you tell me if you have this problem with this 
>> >> > extension (PHP8 / 7/5>):
>> >> > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>> >> >
>> >> > At the moment I need to check some dependency to try your extension.
>> >> > I'll keep you informed.
>> >> >
>> >> > Best Regards
>> >> >
>> >> > Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a 
>> >> > écrit :
>> >> >>
>> >> >> That's... sort of... irrelevant for this question; the problem appears
>> >> >> before that step. You could make a tarball of the built extension,
>> >> >> create a .deb archive, whatever; the point is that it should be
>> >> >> installable standalone (think e.g. 'apt-get install php81-imagick').
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  
>> >> >> wrote:
>> >> >> >
>> >> >> > Hello,
>> >> >> >
>> >> >> > Can you tell me what the program is in step 7)
>> >> >> >
>> >> >> > > pac

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Glash Gnome]

Right.
> configure && make && make install
works.

For my personal information : Now which command should I use to get the
error ?


Le jeu. 9 déc. 2021 à 17:34, David Zuelke  a écrit :

> Of course a 'make && make install' works. That is *not* what's broken
> since 8.1, and not what I'm talking about.
>
>
> On Thu, Dec 9, 2021 at 4:53 PM Glash Gnome  wrote:
> >
> > Thanks a lot.
> > I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
> > And I can't reproduce the error with my build procedure.
> > But, if I use "make -d install' insteadof "make && make install' I get
> errors.
> >
> > Can you confirm it ?
> >
> >
> >
> >
> >
> > Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a
> écrit :
> >>
> >> Yes, of course; it happens with any extension, because the Makefile
> >> generated by 8.1's 'phpize' now lists those header dependencies even
> >> for 'make install'.
> >>
> >> Like I described, you can reproduce this by 'make'ing the extension,
> >> then moving the PHP you used to build the extension, then running
> >> 'make install' (sample with your ext, on my build environment for
> >> Heroku's PHP support):
> >>
> >> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
> >> root@8f6813d6dc88:/app# which php
> >> /app/.heroku/php/bin/php
> >> root@8f6813d6dc88:/app# php -v
> >> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
> >> Copyright (c) The PHP Group
> >> Zend Engine v4.1.0, Copyright (c) Zend Technologies
> >> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
> >>
> >> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
> >> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
> >> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
> >> https://github.com/gtkphp/php-ext-cairo-src
> >> Cloning into 'php-ext-cairo-src'...
> >> …
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
> >> origin/PHP-8.0
> >> Note: checking out 'origin/PHP-8.0'.
> >>
> >> You are in 'detached HEAD' state. You can look around, make experimental
> >> …
> >>
> >> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
> >> Configuring for:
> >> PHP Api Version: 20210902
> >> Zend Module Api No:  20210902
> >> Zend Extension Api No:   420210902
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
> >> --prefix=/app/.heroku/php
> >> …
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
> >> …
> >> Build complete.
> >> Don't forget to run 'make test'.
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
> >> /app/.heroku/php{,_}
> >>
> >> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
> >> make: *** No rule to make target
> >> '/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
> >> Stop.
> >>
> >>
> >> On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome 
> wrote:
> >> >
> >> > Thanks, I'll check it out.
> >> >
> >> > I'm confused. Can you tell me if you have this problem with this
> extension (PHP8 / 7/5>):
> >> > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
> >> >
> >> > At the moment I need to check some dependency to try your extension.
> >> > I'll keep you informed.
> >> >
> >> > Best Regards
> >> >
> >> > Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a
> écrit :
> >> >>
> >> >> That's... sort of... irrelevant for this question; the problem
> appears
> >> >> before that step. You could make a tarball of the built extension,
> >> >> create a .deb archive, whatever; the point is that it should be
> >> >> installable standalone (think e.g. 'apt-get install php81-imagick').
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome 
> wrote:
> >> >> >
> >> >> > Hello,
> >> >> >
> >> >> > Can you tell me what the program is in step 7)
> >> >> >
> >> >> > > package up
> >> >> >
> >> >> > Thanks you,
> >> >> >
> >> >> >
> >> >> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals <
> internals@lists.php.net> a écrit :
> >> >> >>
> >> >> >> Hi all,
> >> >> >>
> >> >> >> When building shared extensions for PHP for the purpose of
> packaging
> >> >> >> and distributing the builds, the build environment obviously
> needs PHP
> >> >> >> installed in the destination directory structure (for headers,
> phpize,
> >> >> >> and so forth).
> >> >> >>
> >> >> >> But the resulting archive of the built extension should only
> contain
> >> >> >> the shared object, and possibly the headers.
> >> >> >>
> >> >> >> A common pattern to do achieve is:
> >> >> >>
> >> >> >> 1) download/extract PHP to $installdir
> >> >> >> 2) download/extract extension to $builddir
> >> >> >> 3) phpize in $builddir
> >> >> >> 4) make in $builddir
> >> >> >> 5) rm -rf $installdir
> >> >> >> 6) make install
> >> >> >> 7) package up $installdir
> >> >> >>
> >> >> >> Step 6 installs the extension into $installdir - you end up with
> >> >

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[David Zuelke via internals]

Of course a 'make && make install' works. That is *not* what's broken
since 8.1, and not what I'm talking about.


On Thu, Dec 9, 2021 at 4:53 PM Glash Gnome  wrote:
>
> Thanks a lot.
> I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
> And I can't reproduce the error with my build procedure.
> But, if I use "make -d install' insteadof "make && make install' I get errors.
>
> Can you confirm it ?
>
>
>
>
>
> Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a écrit :
>>
>> Yes, of course; it happens with any extension, because the Makefile
>> generated by 8.1's 'phpize' now lists those header dependencies even
>> for 'make install'.
>>
>> Like I described, you can reproduce this by 'make'ing the extension,
>> then moving the PHP you used to build the extension, then running
>> 'make install' (sample with your ext, on my build environment for
>> Heroku's PHP support):
>>
>> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
>> root@8f6813d6dc88:/app# which php
>> /app/.heroku/php/bin/php
>> root@8f6813d6dc88:/app# php -v
>> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
>> Copyright (c) The PHP Group
>> Zend Engine v4.1.0, Copyright (c) Zend Technologies
>> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
>>
>> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
>> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
>> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
>> https://github.com/gtkphp/php-ext-cairo-src
>> Cloning into 'php-ext-cairo-src'...
>> …
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
>> origin/PHP-8.0
>> Note: checking out 'origin/PHP-8.0'.
>>
>> You are in 'detached HEAD' state. You can look around, make experimental
>> …
>>
>> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
>> Configuring for:
>> PHP Api Version: 20210902
>> Zend Module Api No:  20210902
>> Zend Extension Api No:   420210902
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
>> --prefix=/app/.heroku/php
>> …
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
>> …
>> Build complete.
>> Don't forget to run 'make test'.
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
>> /app/.heroku/php{,_}
>>
>> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
>> make: *** No rule to make target
>> '/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
>> Stop.
>>
>>
>> On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
>> >
>> > Thanks, I'll check it out.
>> >
>> > I'm confused. Can you tell me if you have this problem with this extension 
>> > (PHP8 / 7/5>):
>> > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
>> >
>> > At the moment I need to check some dependency to try your extension.
>> > I'll keep you informed.
>> >
>> > Best Regards
>> >
>> > Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a écrit 
>> > :
>> >>
>> >> That's... sort of... irrelevant for this question; the problem appears
>> >> before that step. You could make a tarball of the built extension,
>> >> create a .deb archive, whatever; the point is that it should be
>> >> installable standalone (think e.g. 'apt-get install php81-imagick').
>> >>
>> >>
>> >>
>> >> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome  wrote:
>> >> >
>> >> > Hello,
>> >> >
>> >> > Can you tell me what the program is in step 7)
>> >> >
>> >> > > package up
>> >> >
>> >> > Thanks you,
>> >> >
>> >> >
>> >> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals 
>> >> >  a écrit :
>> >> >>
>> >> >> Hi all,
>> >> >>
>> >> >> When building shared extensions for PHP for the purpose of packaging
>> >> >> and distributing the builds, the build environment obviously needs PHP
>> >> >> installed in the destination directory structure (for headers, phpize,
>> >> >> and so forth).
>> >> >>
>> >> >> But the resulting archive of the built extension should only contain
>> >> >> the shared object, and possibly the headers.
>> >> >>
>> >> >> A common pattern to do achieve is:
>> >> >>
>> >> >> 1) download/extract PHP to $installdir
>> >> >> 2) download/extract extension to $builddir
>> >> >> 3) phpize in $builddir
>> >> >> 4) make in $builddir
>> >> >> 5) rm -rf $installdir
>> >> >> 6) make install
>> >> >> 7) package up $installdir
>> >> >>
>> >> >> Step 6 installs the extension into $installdir - you end up with
>> >> >> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
>> >> >>
>> >> >> That doesn't work with PHP 8.1 anymore - the Makefile generated by
>> >> >> phpize now contains an include directive at the top level (near the
>> >> >> bottom), e.g.:
>> >> >>
>> >> >> -include src/php_raphf_api.dep
>> >> >>
>> >> >> Which lists not only the extension's headers, but also all of PHP's
>> >> >> (in include/main, include/Zend, and so forth):
>> >> >>
>> >> >> src/php_raphf_a

Re: [PHP-DEV] Why do PHP 8.1 extensions need PHP headers during make install (worked in <8.1)?

[Glash Gnome]

Thanks a lot.
I use PHP 8.2.0-dev (cli) (built: Dec  8 2021 23:53:19) (NTS)
And I can't reproduce the error with my build procedure.
But, if I use "make -d install' insteadof *"make && make install'* I get
errors.

Can you confirm it ?





Le jeu. 9 déc. 2021 à 03:19, David Zuelke  a écrit :

> Yes, of course; it happens with any extension, because the Makefile
> generated by 8.1's 'phpize' now lists those header dependencies even
> for 'make install'.
>
> Like I described, you can reproduce this by 'make'ing the extension,
> then moving the PHP you used to build the extension, then running
> 'make install' (sample with your ext, on my build environment for
> Heroku's PHP support):
>
> root@8f6813d6dc88:/app# export PATH=/app/.heroku/php/bin:$PATH
> root@8f6813d6dc88:/app# which php
> /app/.heroku/php/bin/php
> root@8f6813d6dc88:/app# php -v
> PHP 8.1.0 (cli) (built: Dec  8 2021 20:43:30) (NTS)
> Copyright (c) The PHP Group
> Zend Engine v4.1.0, Copyright (c) Zend Technologies
> with Zend OPcache v8.1.0, Copyright (c), by Zend Technologies
>
> root@8f6813d6dc88:/app# mkdir /tmp/build-ext-cairo
> root@8f6813d6dc88:/app# cd /tmp/build-ext-cairo/
> root@8f6813d6dc88:/tmp/build-ext-cairo# git clone
> https://github.com/gtkphp/php-ext-cairo-src
> Cloning into 'php-ext-cairo-src'...
> …
>
> root@8f6813d6dc88:/tmp/build-ext-cairo# cd php-ext-cairo-src/
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# git checkout
> origin/PHP-8.0
> Note: checking out 'origin/PHP-8.0'.
>
> You are in 'detached HEAD' state. You can look around, make experimental
> …
>
> HEAD is now at 2cd2ce9 Fix test( compatibility PHP-8)
>
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# phpize
> Configuring for:
> PHP Api Version: 20210902
> Zend Module Api No:  20210902
> Zend Extension Api No:   420210902
>
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# ./configure
> --prefix=/app/.heroku/php
> …
>
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make -j9
> …
> Build complete.
> Don't forget to run 'make test'.
>
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# mv
> /app/.heroku/php{,_}
>
> root@8f6813d6dc88:/tmp/build-ext-cairo/php-ext-cairo-src# make install
> make: *** No rule to make target
> '/app/.heroku/php/include/php/main/php.h', needed by 'cairo.lo'.
> Stop.
>
>
> On Thu, Dec 9, 2021 at 2:30 AM Glash Gnome  wrote:
> >
> > Thanks, I'll check it out.
> >
> > I'm confused. Can you tell me if you have this problem with this
> extension (PHP8 / 7/5>):
> > https://github.com/gtkphp/php-ext-cairo-src checkout PHP-8.0
> >
> > At the moment I need to check some dependency to try your extension.
> > I'll keep you informed.
> >
> > Best Regards
> >
> > Le jeu. 9 déc. 2021 à 01:20, David Zuelke  a
> écrit :
> >>
> >> That's... sort of... irrelevant for this question; the problem appears
> >> before that step. You could make a tarball of the built extension,
> >> create a .deb archive, whatever; the point is that it should be
> >> installable standalone (think e.g. 'apt-get install php81-imagick').
> >>
> >>
> >>
> >> On Thu, Dec 9, 2021 at 12:33 AM Glash Gnome 
> wrote:
> >> >
> >> > Hello,
> >> >
> >> > Can you tell me what the program is in step 7)
> >> >
> >> > > package up
> >> >
> >> > Thanks you,
> >> >
> >> >
> >> > Le mer. 8 déc. 2021 à 16:25, David Zuelke via internals <
> internals@lists.php.net> a écrit :
> >> >>
> >> >> Hi all,
> >> >>
> >> >> When building shared extensions for PHP for the purpose of packaging
> >> >> and distributing the builds, the build environment obviously needs
> PHP
> >> >> installed in the destination directory structure (for headers,
> phpize,
> >> >> and so forth).
> >> >>
> >> >> But the resulting archive of the built extension should only contain
> >> >> the shared object, and possibly the headers.
> >> >>
> >> >> A common pattern to do achieve is:
> >> >>
> >> >> 1) download/extract PHP to $installdir
> >> >> 2) download/extract extension to $builddir
> >> >> 3) phpize in $builddir
> >> >> 4) make in $builddir
> >> >> 5) rm -rf $installdir
> >> >> 6) make install
> >> >> 7) package up $installdir
> >> >>
> >> >> Step 6 installs the extension into $installdir - you end up with
> >> >> /foo/bar/lib/php/extensions/no-debug-non-zts-20210902/something.so
> >> >>
> >> >> That doesn't work with PHP 8.1 anymore - the Makefile generated by
> >> >> phpize now contains an include directive at the top level (near the
> >> >> bottom), e.g.:
> >> >>
> >> >> -include src/php_raphf_api.dep
> >> >>
> >> >> Which lists not only the extension's headers, but also all of PHP's
> >> >> (in include/main, include/Zend, and so forth):
> >> >>
> >> >> src/php_raphf_api.lo:
> /tmp/bob-2eBC7e/raphf-2.0.1/src/php_raphf_api.c \
> >> >>  config.h /app/.heroku/php/include/php/main/php.h \
> >> >>  /app/.heroku/php/include/php/main/php_version.h \
> >> >>  /app/.heroku/php/include/php/Zend/zend_stream.h \
> >> >>  /app/.heroku/php/include/php/main/streams/php_str

Re: [PHP-DEV] Allow default parameters before non-default ones?

[Christoph M. Becker]

On 09.12.2021 at 13:03, Rowan Tommins wrote:

> On 09/12/2021 05:22, André Hänsel wrote:
>
>> If I try the same thing in PHP 8.0 I get a Deprecated warning and if I
>> try
>> it in PHP 8.1 I get something that I don't understand:
>> https://3v4l.org/cg4DA
>
> There are two diagnostics showing in 8.1, the deprecation on the
> declaration, and a fatal error on the call.
>
> What's happened is that given your signature:
>
>> function blah($foo = "deffoo", $bar) { ... }
>
> PHP has decided it doesn't make sense, and re-interpreted it as this:
>
>> function blah($foo, $bar) { ... }
>
> Then when you try to call it:
>
>> blah(bar: "1");
>
> You're missing the now-mandatory parameter $foo, so you get a fatal error.
>
>
> I'm not sure exactly why this behaviour has changed, and can't see any
> mention in the Release or Migration pages in the manual. It's not a
> *huge* break, because named params have only existed since 8.0, but it
> is technically a breaking change in a minor version.
>
> The only relevant discussion I've found is this, where Nikita is I think
> hinting at the new behaviour: https://externals.io/message/114007#114026

The new behavior has been introduced[1] quite a while after this mail
had been sent.  I agree with the idea outlined in the commit message.

I suggest to document that in the migration guide, and in the manual proper.

[1]


--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Allow default parameters before non-default ones?

[Rowan Tommins]

On 09/12/2021 05:22, André Hänsel wrote:

If I try the same thing in PHP 8.0 I get a Deprecated warning and if I try
it in PHP 8.1 I get something that I don't understand:
https://3v4l.org/cg4DA



There are two diagnostics showing in 8.1, the deprecation on the 
declaration, and a fatal error on the call.


What's happened is that given your signature:

> function blah($foo = "deffoo", $bar) { ... }

PHP has decided it doesn't make sense, and re-interpreted it as this:

> function blah($foo, $bar) { ... }

Then when you try to call it:

> blah(bar: "1");

You're missing the now-mandatory parameter $foo, so you get a fatal error.


I'm not sure exactly why this behaviour has changed, and can't see any 
mention in the Release or Migration pages in the manual. It's not a 
*huge* break, because named params have only existed since 8.0, but it 
is technically a breaking change in a minor version.


The only relevant discussion I've found is this, where Nikita is I think 
hinting at the new behaviour: https://externals.io/message/114007#114026



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Allow default parameters before non-default ones?

[Deleu]

On Thu, Dec 9, 2021 at 6:48 AM Mark Randall  wrote:

> On 09/12/2021 05:22, André Hänsel wrote:
> > This is very useful because I can add an optional parameter to a function
> > and prevent users of my function from using the parameter in a positional
> > way. This way I don't have to make a compatibility promise to never
> change
> > the position of this parameter.
>
>
> I would much prefer we could find a way to give this proper support
> rather than a hack.
>
> I frequently use large numbers of named arguments and would very much
> like to be able to knock out the ability to use positional arguments,
> thus ensuring I can change the order (e.g. inserting a new argument
> after a related one) without a BC break.
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
If this were to happen, would it be an attribute to be added to the
functions, a new keyword to declare named-parameter functions only or a
different way to declare parameters? Are there other options?

-- 
Marco Aurélio Deleu