fix headless support

[sleepybishop]

Hello! This PR cleans up and refactors the headless compilation support in LinuxCNC.

There is a need to run LinuxCNC on constrained or strictly headless hardware where X11, Tk, and GTK dependencies are unnecessary overhead.

To bridge this gap, this PR modifies the build system to allow LinuxCNC to be built and run completely without GUI dependencies (using --disable-gui and --disable-gtk).

My intent for this work is to allow orchestrating LinuxCNC entirely via linuxcncrsh and other remote control methods I am currently developing but this first pass just allows for a lighter weight build on devices that don't need the graphical tools, docs or man pages.

Please let me know if you have any feedback or suggestions on this approach or the build system modifications.

[BsAtHome]

May be a good idea to have on the side. But it fails CI quite hard on the hostmot2 driver.

[sleepybishop]

Thanks for looking, not quite ready for primetime. I'm working through the issues. Ill undraft the pr once I have it sorted.

[BsAtHome]

I'm not sure why you suddenly need to check for ld and objdump. These are bog standard from binutils. Or is there something I'm missing here?

[BsAtHome]

Something else... You can only control part of the machine through linuxcncrsh. A large part is controlled/monitored via HAL. For full headless/remote you probably also need halrmt. You are lucky, because that was just "fixed" (bugs notwithstanding).

Still, I'm not sure that everything is in place for real headless operation. Might need quite a bit of extra work to fill any gaps. Anyway, as I said, it still is a nice option to have available. So keep up the work.

[sleepybishop]

Thanks for the feedback. To provide a bit more context, I have a fleet of machines with linuxcnc that I orchestrate remotely. I have a custom branch with a service that provides the equivalent of halrmt via a rest api, they also run a custom linuxcncrsh and a gcode streaming sink.

I'm in the process of extracting useful bits from my branch into upstream. I thought headless support would be a good next step but I accidentally pulled in other buildroot cross-compilation changes hence the ld/objdump stuff. The hostmot driver breakage was due to the inclusion of an old module I wrote that's not useful for upstream.

I've reverted all the changes that are not directly related to a light weight headless build.

[grandixximo]

Looks ready, @BsAtHome do we want a CI job to test the --disable-gui path? I could do that follow up if we want it..

[BsAtHome]

Looks ready, @BsAtHome do we want a CI job to test the --disable-gui path? I could do that follow up if we want it..

The idea to build without GUI is a good one. But we might want to think this through and want to define where this needs to go (or just a one-off option?).

There are a few problems. You cannot currently build a package that is created with --disable-gui. There should probably be a mechanism to create a linuxcnc-nogui-*.deb. And when we go that path, it might be a thought to think this through a bit further and instead create linuxcnc-base-*.deb and then several linuxcnc-gui-XYZ*.deb?

And, when you build without man-pages, then you cannot build a package because they are a requirement when building a package (Debian ant man-pages for each program). I'm not sure I see the reason for building without man-pages. These are probably the least of anybody's problem.

[grandixximo]

I was just thinking rip build in CI to test the flag does not break in rip builds at least...
But yeah I see the point, bigger discussion for later....

[sleepybishop]

Thanks for thinking through this folks. My intent was to implement this for source builds like my buildroot setup. My intent with the man pages was that they are simply not needed on a headless machine and omitting them results in a slimmer build.

For packaging, building everything and creating subpackages would be more appropriate as you suggested, (A core + ancillary packages), but that was out of scope from my intended changes.

Please let me know if source builds are discouraged, then I'll skip bringing over my buildroot cross-compilation changes and look for more meaningful changes to contribute.

[grandixximo]

I don't think source builds changes or extensions are discouraged, building with cmake has been discussed multiple times, but I do think if we take this in as a supported flag, we should test that it keeps working. If most people show up at the meeting, we will probably merge I imagine, and maybe talk a bit about the packaging thing, I still don't see the strong points for it very clearly.