Referencing/Opening one binary in another binary

[Jan200101]

I am working on a project that has two types of binaries: the Service and the Worker.
At the end the Worker is going to be spawned by the Service to do tasks that the Service cannot do on its own but how can the Service reference the Worker?

In the best case both binaries and the CWD are in the same folder and I can just open them, but that is not always the case, especially not when invoked with zig build run.
I’ve thought about using Step.Compile.getEmittedBin in the build system but that would then reference the cache artifact and not wherever it is installed at the end.

Maybe the best solution is to look in the local directory first and then somewhere else? Has anyone done this before?

[alanza]

I think I’m missing what you are trying to do. Is the point that you want something like std.process.Child, but you don’t know what argv[0] (i.e. /path/to/Worker) should be?

another solution, potentially, would be to use something like fork more directly in your code?

[Jan200101]

@alanza

I think I’m missing what you are trying to do. Is the point that you want something like std.process.Child, but you don’t know what argv[0] (i.e. /path/to/Worker) should be?

Practically this.
The actual implementation is going to actually execute bubblewrap and pass the Worker into the container either via path or file handle.

[alanza]

gotcha. well, I’m still not sure, but probably whoever is sure to know where the file is should be made responsible for telling Service that. one way to do this within the build system is the addFileArg method on Step.Run which can be passed a LazyPath

[Jan200101]

@Jan200101

I’ve thought about using Step.Compile.getEmittedBin in the build system but that would then reference the cache artifact and not wherever it is installed at the end.

Turns out that does not work because std.Build.LazyPath is a union and those are not supported as build options yet.
0.17 is going to get remove LazyPath.getPath() so that isn’t an option in the long-term.

@alanza

one way to do this within the build system is the addFileArg method on Step.Run which can be passed a LazyPath

I think that’s gonna be the short-term solution I go with but I gotta figure out how to deal with this when installing.

It doesn’t help that accessing the install prefix in the build system is unsupported so I wouldn’t even be able to stitch together a path to it.

[Sze]

@Jan200101

I’ve thought about using Step.Compile.getEmittedBin in the build system but that would then reference the cache artifact and not wherever it is installed at the end.

Have you tried using this:

Removal of getInstallPath

That’s incorrect, it is specifically designed for system installs. There is literally a --system flag for this. The main issue is that the install path should not be observed in the configure phase. You can construct a LazyPath based on the install path instead which will avoid re-running the configure phase when the user changes install path. Check out std.Build.Graph.path

I think you could create the install-lazy-path with that and then use std.Build.addRunFile to create the run-step to run it?

Haven’t updated yet so I am unsure it would work, but seems theoretically possible.

[Jan200101]

@Sze

I think you could create the install-lazy-path with that and then use std.Build.addRunFile to create the run-step to run it?

Haven’t updated yet so I am unsure it would work, but seems theoretically possible.

Yeah, that’s gonna be the short term solution.

[vulpesx]

Would it be reasonable to require the server and worker executables to be installed in the same directory?

Because you can get that with std.process.executableDirPath

[Jan200101]

That actually works perfectly and I completely forgot that exists, thanks.