• AppVeyor output when xmlrpc extension is enabled: https://ci.appveyor.com/project/mlocati/php-src/build/1.0.20/job/appdaok8gice8ris => build fails
• AppVeyor output when xmlrpc extension is disabled: https://ci.appveyor.com/project/mlocati/php-src/build/1.0.19/job/2foc76s4mu5pwwbm => tests fail

@mlocati Looks like Anatol just fixed the libxml compile: ab52afb

@mlocati Looks like Anatol just fixed the libxml compile: ab52afb

Thanks! Let's see AppVeyor results... https://ci.appveyor.com/project/mlocati/php-src

AppVeyor build is successful, now

@mlocati nice work! Thanks for bringing it here. IMHO, the more integration we have, the more quality is to expect.

Yep, as mentioned, some changes to the SDK are to expect. It possibly can affect, how the deps are updated and handled otherwise. Also, the changes to the tools can make some impact on the script. It might be just a minor impact, or require a bit more. Therefore i think it would make sense to have the SDK changes first, and then to coordinate with integration of this PR into master. Afterwards, backporting were also thinkable.

Meanwhile, the comments i'd drop on the existing approach

• one test run needs to be done with Opcache
• at least one TS and one NTS runs should be
• would make sense to test on different Windows images, if possible (to discuss which)
• the above are causing too much varianst, of course. We need to check which minimal set is needed. And imho, it were ok to concentrate just on x64 builds under this circumstances.
• it'd make sense also to add some databases as well, at least pgsql, mysqli and pdo_* variants
• with an extra config, it could be possible to gather dumps or backtraces on crashing tests
• starting with 7.1 also, more static analysis tools are integrated, whereby
  • unfortunately, there are currently issues with VC
  • though, IMHO it could be checked to enable cppcheck, if it's not too slow

For more far future, maybe

• other exts, like odbc, ftp, ldap, interbase and a couple of others, could be tested as well. Some of the setup automations are quite cheap
• currently there's no valgrind alternative, we might think about doing same with drmemory or another tool at some point, @pierrejoye made some promising checks in the direction
• might think about itegration with the irc bot, even it's more spam as travis is integrated already :)

These are just some loud thoughts, as i'm not yet into appveyor opportunities. You're for sure informed better in the matter.

Another question also - i saw that appveyor.com accepts github accounts. Do you possibly know, whether we would have to register with the github organization, or it'd be enough one member to do that? Just asking to have an approx idea, what will be needed, no exact infos, clear. I think we'll also need to discuss this on internals, so this change is well communicated and we determine the best way to handle the integration.

Thanks.

Another catch up, i've just seen some lines like

Checking for bison.exe ... \cygwin\bin

which doesn't sound right. Only the tools from the php-sdk and vs should be used.

Thanks.

Another catch up, i've just seen some lines like
Checking for bison.exe ... \cygwin\bin
which doesn't sound right. Only the tools from the php-sdk and vs should be used.

Maybe there could be a cleaner solution, but I've had to be quite brutal to solve this... 97112fe 😉

i saw that appveyor.com accepts github accounts. Do you possibly know, whether we would have to register with the github organization, or it'd be enough one member to do that?

I'd contact them directly: I bet they'll be quite happy to have PHP listed in their users list

Ok, i've got a response from the AppVeyor team. It looks good from its side, so we can integrate the PHP org.

Two points i've got from there:

• usage of custom images is not available
• free accounts job runs are limited to one concurrent job and max time of one hour per job

This reduces the test possibilities of course. I would suggest the following therefore, so we start and try how it goes

• one test run of NTS x64 build
• one test run of TS x64 build + Opcache
• enabled ext/mysql and ext/pdo_mysql, so need some server

If we see that the runs finish in some acceptable amount of time, we can decide to either put more runs or to extend with other options like other DBs, static analysis, etc. For now, it'd also make sense to check, how the button integrates with the README.md, not a big deal probably.

These steps are already doable. I'm still working on the new PHP SDK in meanwhile, but there should be no interference on these points.

Regarding the org registration, there's an article https://www.appveyor.com/docs/team-setup/#github-integration . I'm reaching to internals next days in this regard. After that, if everything is ok, we'll be a step forward on the way to the goal.

Thanks.

Can this be extended to also work for extensions, such as Xdebug? I would want to run this on my own GitHub repo of course...

I'd also be interested in that.

I'm using appveyor but the build process is rather complicated, it would be nice if the build environment could somehow be loaded for external projects too ...

@krakjoe, @derickr as discussed on IRC, for non core some extra setups are rather required. I didn't go for the ApVeyor registration yet, so dunno if it can only be given right for php-src, or it'll request to read all the repos. For the PECL exts migrated to git, it's likely to work similar with some extra configuration and would be shows under the PHP org. Lets see, once the registration is done.

Thanks.

@mlocati there's now a worky version of new SDK there. Work in progress, but already stable enough to start to work with.

The basic point to care about

• there's a starter script, which should be used to setup the SDK environment
• phpsdk_deps can be used to update the deps in the cache

Please, let me know if there are some issues or questions.

Thanks.

@weltling Do you mean something like this?

PS: I'll work on the new PHP SDK on my appveyor-newsdk branch until I'll be able to get a working build script.

@mlocati with the starter script, the amount of required setup is significantly reduced. It is possible to do something similar to this

"C:\php-sdk\phpsdk-starter.bat -c vc14 -a x64 -t C:\php-sdk\test-build-php-7.0-task.bat"

or this

"C:\php-sdk\phpsdk-vc14-x64.bat -c vc14 -a x64 -t C:\php-sdk\test-build-php-7.0-task.bat"

The idea of the starter script is, that all the environment, including VS shell and SDK tools paths, is setup at once. Fe you can check if you click on that file locally. Once the starter file is invoked, the only what is to be done is to switch into the build directory and do the build and test.

The task script from the example above gets embedded into the cmd where all the previous setups are run. Some useful env vars are then available, you can check them with something like set | find "PHP_SDK_" and use, if needed. The behavior is the same as when starting the interactive shell (fe by just clicking the starter). Just the starter script is run with cmd /c and is going to exit at the end, unlike interactive shell is started with cmd /k and will persist. I've also included a sample task script in the doc directory in the repo.

Within the task script, a command like this could be useful

phpsdk_deps -u -b 7.0 -a x64 -d C:\php-sdk\php70\vc14\x64\deps

The deps won't be fetched everytime the command run, but only if there are some changed deps available. In that case, it's good you hold them in the cache. As a side effect, it'll currently save a backup copy of the previous deps dir, so it might need to be removed manually. Or probably an option to phpsdk_deps could be implemented, so it doesn't backup.

I might good have missed something, but in general these notes are the essential part of what has changed. Hopefully it'll simplify not only the dev work, but also the tasks like this one.

Thanks.

@mlocati, hi :) How's the status? Do you need some help? I'm going to spend some days this week on the further master snapshot integration, could do a PR against your branch.

Thanks.

hi :) How's the status?

You know these periods when for every project you finish you have to start three new ones? ... 😫

could do a PR against your branch

You can also start a new branch on your own and grab all the code you want, no copyright issues 😉 Feel free to do whatever you want

Oh, that's a perfect description of Hydra :) Jokes aside - that's probably the best way to ensure ones job.

In this situation, I'm certainly intended to take over. Lets see, how far i'll come in the near future. Thanks for all the preceding work!

Thanks.

If you start a new branch, please let me know... If I can find some agents of the Shield that can help me, I might defeat the Hydra and find some spare time to contribute 😉

FYI - the continuation is in #2229. Rewrote the relevant parts with cmd, for simplicity, integrated with the new SDK and deps fetching, some test fixes yet to go. Closing this, lets move to the other one for the further discussion.

Thanks.