I added a test for WebServerConfig class. In first commit the test is added for the existing implementation. Then a change commit adds the "executable" parameter and tests that it works as expected.

I still couldn't properly test whether the code works as a whole (see first message) and would very much welcome any suggestions on how to do it.

Instead of adding an option for an edge case, I propose to be able to configure the executable via an env var.

I was working on the very same issue, but I came with a different approach:3.4...xurumelous:feature/cli-settings-server

I did not change the$binary variable , only added support for php settings definition:php bin/console server:run localhost:8001 -c 'xdebug.remote_port=9001' -c 'xdebug.idekey=SAMPLE'. It is a bit more limited, since a custom php.ini cannot be set.

@fabpot that makes sense. I'll try to update the code asap.

@xurumelous yes, I thought about that as well. It's actually what most people use when debugging CLI apps. But it would not work for my case. If you look at#22101 - my exact use cases is xdebug wrapper for the php binary. What's great about it is that you have centralized configuration and all you need to know is that you need to callxdebug instead ofphp. I always had a hard time describing someone how to pass the params - which is why I created the wrapper. It's setup once and forget. Also you may have multiple PHP versions and want to run it in a specific one (i.e. test something in 7.0 even though 7.1 is your default).

@tomasfejfar Yes, it makes sense. Are you making the change for the env variable? If you need help you can count on me. I really need to be able to set xdebug.remote_port per project. Right now I'm basically doing it manually, getting the command theserver:run would run and running it myself.

This implementation should allow you to set the executable tophp -dxdebug.remote_port=123

If you could do the change for the env variable and send a PR from your fork to this branch, that would be great. I'll probably not have time for it this week.

Did you manage to test your changes somehow? How did you approach it? I've coded the whole thing without ever running it because I couldn't get it to work (as noted in the first post) :(

@fabpot what about setting the executable as a parameter and pulling it from the DI? I would prefer changingparameters.yml to fiddling with ENV variables. Also it could have specific settings for different envs (dev/prod).

@tomasfejfar I believe I'll have time for this later today or tomorrow night.

I tested in the vendor folder. I ran composer with--prefer-source option, so it cloned the repository for each dependency. I worked on this in the vendor folder, when it was ready, I patched my fork with the changes I made (git diff >> /tmp/patch thenpatch -p1 < /tmp/patch in my fork). I'm not very used to Symfony development, but that was my workaround to test it before running.

I thought you have tested it, so I did not mention one issue before, I'll comment on the line I'm talking about.

I kept the various commits to allow easy revert if some of them are not OK.

Tested on Windows:

php index.php s:r --docroot web\SET SYMFONY_SERVER_EXECUTABLE=xdebug&&php index.php s:r --docroot web\SET SYMFONY_SERVER_EXECUTABLE=php -dmemory_limit=512M -dinclude_path="c:\\Program Files"&& php index.php s:r --docroot web\

Works as expected.

All green. Ready for review.

Can I do anything else to move this forward?

Any update on this?

what about not allowing command line args in the new env var?

Oh btw, if you follow this path, what about putting that env var in PhpExecutableFinder?

Moving to 4.1. Rebase on master might be needed, where PHP 7.1 features can be used btw.