I am not sure if [process] is the right library, but I am thinking about building something to manage daemon install/uninstall across platforms, for example Windows's service, OS X's launchd, systemd, and SysV init. Every operating system offers some way to launch a daemon at boot, and also the ability to stop, recover, etc. The issue is they all do it slightly differently, unlike having a common main(). My thinking is to provide a thin layer for install/remove and service notification. I have looked at Boost.Application, but it's lacking install/uninstall, and also seems overly complicated.
Thoughts?
Boost.Process is definitely the wrong library for that, it is more about launching processes, then being a process; the latter would be boost.application. I am also not sure, why this would be a C++ library and not just an install script. I.e. wouldn't the daemon be written in C++ but the installation wouldn't need to be done in C++ - I'm not sure what the benefit would be. But I do think an application approach would be the right one for this problem; be it part of boost.application or not. Probably the simplest solution would be, that the library already has the different entry points, and you need to add functions, similar to main, though they might be called "recover", "start", "stop". I don't know how active the development of boost.application is, but maybe you can help there and add a daemon-feature; or you build your own version of that. If I personally see a very complicated library, I mostly get cautious, because I might be underestimating the complexity of a problem.
Here are mine:
1. The feature seems interesting to me. 2. I'm not sure if it should be in Boost.Process, maybe it should just depend on it? I guess it depends a lot on what the implementation needs.
I'll even add features regarding process creation if they are needed for this and fit in the scope of process.
3. I think there was an effort from the Boost.Application proposal to do the same thing. At the time Boost.Application was split into small libraries, and IIRC some of them are now in Boost. So basically there was interest in the daemon part of the project too.
You are in fact correct, Boost.Dll was taken from boost.application.