component compile problem

The simple way to automate G43 is:
linuxcnc.org/docs/2.7/html/remap/remap.h...i_file_configuration
("retain g43")
But I think that a better way is to use the other info on that page to re-map M6.
That means that you can run a G-code subroutine to ensure that conditions are right for a tool change, and then you can add the G43 to the routine.

You can even re-map the "T" command to perform the full tool change, optionally with wear offsets included. see the re-map routine here:
github.com/LinuxCNC/linuxcnc/tree/master...im/axis/lathe-fanucy
(Specifically the toolchange.ngc routine, but not also the notes in the readme and the INI changes to make it happen)

I rarely actively use G-code on my lathe (at least for one-offs)
I do most things with this:
forum.linuxcnc.org/41-guis/26550-lathe-macros?start=150#82743

The screenshot shows it embedded in Touchy, but it can be embedded in any of the other user interfaces as a custom tab.

Native-CAM is more advanced, my macros are little more than power-feed-with-return-and-repeat. But for a lot of lathe work that's all you need.

Carousel might work, though I am a little confused about the rotation sequence.
It looks like it needs to open one valve until a sensor triggers, then it needs to trigger a different valve to lock, and that advances one position.

The carousel comp expects the carousel to carry on moving through successive pocket positions all the time that the "motor-fwd" pin is held high.

In this case I think it might be simplest to do it all as a G-code subroutine or a dedicated HAL component as it is quite a simple sequence and interpreting the position sensors is fairly easy.

Is there a sensor to indicate that the piston is at the end of travel, or is it done purely on time?

To use "carousel" you would need to use something like a one-shot HAL component to pulse the solenoid valves, and at that point there is more happening outside carousel than inside.

Note that the "tooledit" programme will not allow multiple tools in the same pocket, and your changer seems to require that. You can edit the tool table with a text editor, though, and get the desired result.

Are you more comfortable with G-code or C for the control sequence?

One advantage of using a G-code remap is that you can

This requires a few HAL connections to work.

net tool-prepared motion.digital-out-02 => iocontrol.0.tool-prepared
net M6-loop iocontrol.0.tool-change => iocontrol.0.tool-changed
net pos-1 motion.digital-in-01 <= { hardware input for positionl 1}
net pos-2 motion.digital-in-02 <= { hardware input for positionl 2}
net pos-3 motion.digital-in-03 <= { hardware input for positionl 3}
net pos-4 motion.digital-in-04 <= { hardware input for positionl 4}
net valve-S1 motion.digital-out-00 => {output pin for S1}
net valve-S2 motion.digital-out-01 => {output pin for S2}

Also, the code should check that the pocket number is in range, and it would be wise to have a counter that aborts the tool change after 4 rotations, as that means something has gone wrong if it hasn't found the pocket.