On Tue, Jan 4, 2022, 2:17 AM Pierre Joye wrote:
>
>
> On Tue, Jan 4, 2022, 1:35 AM Horváth V. wrote:
>
>> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>> > Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
>> > might be okayish, though. ICU ships a VS solution file
On 2022. 01. 03. 20:17, Pierre Joye wrote:
it uses msys for autoconf and co support but actually uses vc?
Exactly.
Unless you have another compiler specified in your Conan profile. You
can see in the _platform method that the dictionary is indexed with
self.settings.os and
On Tue, Jan 4, 2022, 1:35 AM Horváth V. wrote:
> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
> > Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
> > might be okayish, though. ICU ships a VS solution file
> > (source/allinone/allinone.sln) which works fine. I
On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
> Oh, that would be an issue. We can't use Cygwin builds; MinGW builds
> might be okayish, though. ICU ships a VS solution file
> (source/allinone/allinone.sln) which works fine. I don't know
> whether using that would be okay for Conan.
No
On 03.01.2022 at 18:03, Horváth V. wrote:
> Thanks for the reply. It's very helpful.
>
> The glib issue is an upstream issue on Windows:
> https://gitlab.gnome.org/GNOME/glib/-/issues/692
Ah, sorry, that shouldn't be a problem (at least for Windows), since we
need *shared* libraries there
Thanks for the reply. It's very helpful.
The glib issue is an upstream issue on Windows:
https://gitlab.gnome.org/GNOME/glib/-/issues/692
ICU's Conan recipe doesn't support some platforms:
On 03.01.2022 at 17:29, Horváth V. wrote:
> I have created an issue to track dependencies for PHP:
> https://github.com/conan-io/conan-center-index/issues/8618
>
> Please take a look, verify that all of those are needed and if anyone
> has answers for the few questions I have as sublist items,
I have created an issue to track dependencies for PHP:
https://github.com/conan-io/conan-center-index/issues/8618
Please take a look, verify that all of those are needed and if anyone
has answers for the few questions I have as sublist items, then that
would help greatly as well.
Regards,
good evening Horváth,
On Thu, Dec 30, 2021, 11:49 PM Horváth V. wrote:
> Like I said in another e-mail, I wish to work on my host OS and this is
> something that would need to be done either way. It won't take me long
> either and PHP has been chugging along nicely so far without CMake.
>
>
Like I said in another e-mail, I wish to work on my host OS and this is
something that would need to be done either way. It won't take me long
either and PHP has been chugging along nicely so far without CMake.
vcpkg has more dependencies missing than Conan and Conan has the
advantage of
On Wed, Dec 29, 2021, 8:02 PM Christoph M. Becker wrote:
> On 29.12.2021 at 13:38, Horváth V. wrote:
>
> > Just a quick update on this in between the holidays.
> >
> > There are indeed quite a few of the libraries provided in the php-src's
> > Windows SDK that are missing from Conan Center
On 29.12.2021 at 18:41, Horváth V. wrote:
> On 2021. 12. 29. 14:02, Christoph M. Becker wrote:
>
>> This is why I suggested to postpone Windows support for now.
>
> This would have to be done either way and I prefer to work from the host
> OS on my computer, especially since the Windows side of
On 2021. 12. 29. 14:02, Christoph M. Becker wrote:
This is why I suggested to postpone Windows support for now.
This would have to be done either way and I prefer to work from the host
OS on my computer, especially since the Windows side of things is what's
messy right now and I don't like
On 29.12.2021 at 13:38, Horváth V. wrote:
> Just a quick update on this in between the holidays.
>
> There are indeed quite a few of the libraries provided in the php-src's
> Windows SDK that are missing from Conan Center Index, which is the
> default remote when fetching dependencies using
Hey internals,
Just a quick update on this in between the holidays.
There are indeed quite a few of the libraries provided in the php-src's
Windows SDK that are missing from Conan Center Index, which is the
default remote when fetching dependencies using Conan.
I have submitted a recipe for
On Thu, 2021-12-16 at 20:15 +0100, Nikita Popov wrote:
> My main question would be how this will affect 3rd party extensions,
> which are currently using autoconf. Will they need to migrate to
> cmake, or will we have to effectively maintain both build systems?
We would have to keep our autoconf
On Tue, Dec 21, 2021, 5:24 AM Christoph M. Becker wrote:
> On 20.12.2021 at 23:01, Horváth V. wrote:
>
> > On 2021. 12. 20. 17:19, Pierre Joye wrote:
> >
> >> We may switch to vcpkg distributions, [...], or the current autoconf
> >> php js port works too.
> >
> > Could you elaborate on what you
On Tue, Dec 21, 2021, 5:02 AM Horváth V. wrote:
> On 2021. 12. 20. 17:19, Pierre Joye wrote:
> > We may switch to vcpkg distributions, [...], or the current autoconf
> > php js port works too.
>
> Could you elaborate on what you mean by these?
>
> The reason why I prefer Conan here is because
On 2021. 12. 21. 13:55, Christoph M. Becker wrote:
vcpkg has a lot of these, but some are completely missing (e.g.
libxpm), and some packages are even on older versions than we
currently use for Windows builds.
Good point, even Conan is missing some of those dependencies. Guess I'll
have to
On 21.12.2021 at 13:37, Horváth V. wrote:
> The point of CMake is that you don't have to care too much about the
> system you are building the software on. The exact same CMake build
> files will work on all platforms that CMake supports. There is no
> "Windows support" specifically when you are
The point of CMake is that you don't have to care too much about the
system you are building the software on. The exact same CMake build
files will work on all platforms that CMake supports. There is no
"Windows support" specifically when you are working with CMake. In fact,
I work on a Windows
On 20.12.2021 at 23:01, Horváth V. wrote:
> On 2021. 12. 20. 17:19, Pierre Joye wrote:
>
>> We may switch to vcpkg distributions, [...], or the current autoconf
>> php js port works too.
>
> Could you elaborate on what you mean by these?
>
> The reason why I prefer Conan here is because they
On 2021. 12. 20. 17:19, Pierre Joye wrote:
We may switch to vcpkg distributions, [...], or the current autoconf
php js port works too.
Could you elaborate on what you mean by these?
The reason why I prefer Conan here is because they provide pre-built
binaries for common setups, so that makes
On Fri, Dec 17, 2021, 10:23 PM Kalle Sommer Nielsen wrote:
> Hi
>
> Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. <
> friendlyan...@hotmail.com>:
> > Yes, gradually phasing the current build system out is the most
> > pragmatic choice, although it will incur some extra maintenance cost for
>
Hi
Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. :
> Yes, gradually phasing the current build system out is the most
> pragmatic choice, although it will incur some extra maintenance cost for
> the time it's still in use, but it's better to do something sooner than
> later. This will also
This is way too early to decide this. This is a decision to be made
when we're actually ready to try publishing it for regular
consumption (not for the people developing it).
Sure. I wasn't expecting concrete answers, just letting people know that
this ought to be considered as well.
It may
On Fri, Dec 17, 2021 at 6:49 AM Horváth V. wrote:
>
> One thing I forgot to ask is what minimum CMake version should php-src
> support in its build scripts? For reference, please take a look at
> repology.org for the packaging status of CMake across a lot of software
> distributions:
On Thu, 16 Dec 2021, 17:53 Horváth V., wrote:
>
> I'm writing to you to find out what the reception here is regarding the
> idea of moving the PHP project to build using CMake.
>
I think this would be a great move overall.
Would the CMake build chain be backported? I'm assuming not, which
One thing I forgot to ask is what minimum CMake version should php-src
support in its build scripts? For reference, please take a look at
repology.org for the packaging status of CMake across a lot of software
distributions: https://repology.org/project/cmake/badges
Please note that the lower
We cannot break that without giving sufficient time to the respective
maintainers to update these extensions to use the new CMake build
system. If we can maintain both build chains for some years
Yes, gradually phasing the current build system out is the most
pragmatic choice, although it will
On 16.12.2021 at 22:31, Horváth V. wrote:
>> I think the answer should be that _eventually_ they should have to
>> migrate, but in the interim we must maintain two build systems.
>
> You are right on the first point, but it is not a requirement for
> php-src to be managed by anything other than
I think the answer should be that _eventually_ they should have to
migrate, but in the interim we must maintain two build systems.
You are right on the first point, but it is not a requirement for
php-src to be managed by anything other than CMake to maintain phpize
functionality for existing
On Thu, Dec 16, 2021 at 1:13 PM Horváth V. wrote:
>
> > My main question would be how this will affect 3rd party extensions,
> > which are currently using autoconf. Will they need to migrate to
> > cmake, or will we have to effectively maintain both build systems?
>
> Unless 3rd party extensions
My main question would be how this will affect 3rd party extensions,
which are currently using autoconf. Will they need to migrate to
cmake, or will we have to effectively maintain both build systems?
Unless 3rd party extensions vendor php-src and/or do something extra
besides what they are
On Thu, Dec 16, 2021 at 6:54 PM Horváth V.
wrote:
> Hello internals,
>
> I'm writing to you to find out what the reception here is regarding the
> idea of moving the PHP project to build using CMake.
>
> I have looked around and I found 2 attempts of doing just that in the
> past (in 2008 via
Hi Horváth,
just wanted to give my +1 on this one. For our use-case (PHP Embed, ZTS,
Static Build) this would greatly simplify our build-system which is already
using CMake in a lot of parts. Unfortunately I am not a CMake expert, but
could offer help in testing and feedback.
Regards,
Michael
Hello internals,
I'm writing to you to find out what the reception here is regarding the
idea of moving the PHP project to build using CMake.
I have looked around and I found 2 attempts of doing just that in the
past (in 2008 via GSoC and something else maybe in 2014 that I couldn't
find the
37 matches
Mail list logo
