How to do software development on MICROOS Kalpa (plasma)?

How do I do traditional configure, make, sudo make install, on MicroOS?

I did my build in /opt/john
and for sudo make install, I dropped to transactional-update shell, and rebooted after.
But the exectuables intended for /usr/local/bin are missing!

Perhaps not surprising in view of way MicroOS works.
but if /opt is mounted in the shell’s choot, why not /home and /usr/local?

I’m going to try with the PREFIX=/usr

But is there a suggested method for such on MicroOS?

Kalpa seems better than alpha to me. I’ve been hammering a lot, and got to my 39th snapshot without issue.

What am I building?
xrdp and xorgxrdp, as the ones in the repos I can’t get to work with systemd on MicroOS, even though they work on normal Tumbleweed.

Thx

Replying for the update.

@jradxl Hi and welcome to the Forum :smile:
You don’t on MicroOS :wink: Use distrobox to create a container and then use that to compile, build and run etc… All done as your user, there is no need to install on the host read-only system.

You would do this work in a distrobox.

At it’s most basic, doing distrobox enter is going to create a podman container, based on Tumbleweed, which you would treat just like any other tumbleweed installation.

Absolutely do not attempt do this sort of work within transactional-update shell That’s not what it’s for.

/usr/local is mounted rw and available for use, but it’s not really neccessary for most cases. If you’re wanting to build stuff from source, the best way to do it, is to do it in a distrobox, and then from within the distrobox do distrobox-export --bin /path/to/binary for CLI applications, for instance, or distrobox-export --app nameofapp for desktop applications (things that provide a .desktop file)

This covers most use cases.

Ah, distrobox-export is the clue as I couldn’t see how something in distrobox could help in running a systemd service such as xrdp, on the host. There is still the issue of libraries as I don’t think xrdp is a static build.
My other alternative is to build a custom RPM package.

@jradxl No, the idea is for you to leave the OS to itself as it could render the system unsupportable… Work with distrobox to see what you can achieve first.