OSX support about boost-process HOT 13 CLOSED

Isn't OSX posix based?

While until now only testing on linux, I tried to adhere to the posix-standard, not the linux implementation.
That is why a few things are optional, such as vfork. So if there is either something not posix-compliant in the library, it would technically be a bug, If it's a OSX specific detail, I'd like to add workarounds for that.

from boost-process.

Hi -
We are scrambling around trying to hit some deadlines. I have this on my list to get back to you. I suspect just trying to run the tests will fail. There are missing includes for one.

Meanwhile, I've backed up to the tried and true 0.5 version. What you have looks promising so I want to get back to providing more information.

from boost-process.

Perfect. I'll see if I find a way to test this on MacOS. And I guess once that works, some Solaris user will complain.

from boost-process.

I just looked over the include and compared them to the open group documentation.

This had only two issues:

sysexits.h

This is for some reason included and not used (I think)

wait.h

I seem to have missed this, it should be <sys/wait.h> not just <wait.h>

Are there any more include issues you get?

from boost-process.

So, I changed the includes to be posix-conforming, i.e. remove sysexits.h and changes wait.h to sys/wait.h. As far as I can see, that makes at least the includes posix-conforming. If you by any chance get a opportunity to test that, the commit is 4d679fb.

from boost-process.

@mjcaisse Any news? Btw: the formal review is next week, so you'd help me out a great deal if you test it on OSX.

from boost-process.

See PR #46.

from boost-process.

Based on PR #46 I tried to build a fix in 663fc69. , but I can't test it. If you find the time, I'd be very grateful if you take a look.

from boost-process.

I'm assuming it is supported now as of 2a7f5bb. Feel free to reopen this issue if anything doesn't work properly on OSX.

from boost-process.

I may be doing something wrong, but it doesn't work for me at all on Mac. I've followed all the examples, and everything compiles and runs (tho I had to add an #include for boost::filesystem's operations.hpp into boost::process's operations.hpp to resolve a missing reference), and exit status is fine.

The weird thing is that even if I try to run programs that don't exist, I still get a process ID for the child.

Tried simple things like touching files in the home directory using the full path, but even that didn't work, which of course it does if I try to run the exact same command in the terminal.

Essentially what I'm doing is this:

boost::process::context ctx;
ctx.work_directory = boost::filesystem::current_path().string();
ctx.environment = boost::process::self::get_environment();

std::vector<std::string> args;
args.emplace_back("xcode4");

auto c(boost::process::launch("premake5"s, args, ctx));
c.wait();

I also tried passing boost::process::find_executable_in_path("premake5") instead, which does give me the correct full path, but it still doesn't work.

I have no pointers. It's just... silently failing.

from boost-process.

@avaskoog I know what you're doing wrong, you're using an ancient version of boost.process.

from boost-process.

Now that's embarrassing. Got the latest from this repo and there we go. Can confirm it works like a charm on Mac. So is it using NSTask now, or still the general POSIX thing?

from boost-process.

Pure posix, just a few workarounds for OSX.

from boost-process.