The code on master is working (I always aim at that), but it is not yet complete. To much Perl code in the individual scripts of X2Go Server. All intelligence will be moved into the Perl module/package API.
I guess, your refactoring will be important for future development.
If the configure file works for system-wide installations, then yes.
I looked a bit into the x2goserver repository. There are several subdirectories. Obviously x2goserver uses recursive make (you certainly know http://miller.emu.id.au/pmiller/books/rmch/). Is there any deep reaon to leave it like that?
Your contribution will be very valuable to X2Go as it allows to make the server code ,,portable''.
You are quite optimistic that I come that far. ;-) First I have to understand the structure of the make process and what all variables in the Makefiles mean. I am tempted to use autotools with a toplevel Makefile.am, but I've already seen a project that heavily rejected to use autotools. So I'd better ask now. Maybe it is more work for me to transform the make process into an autotools supported project, but I have the feeling that via autotools one gets certain things for free (parallel build (yes I understand that's not really important for x2go), 'make check' testing support). That's only a preliminary impression, I must dig deeper into the code before I can really say anything serious.
For your approach: please start on x2goserver first. Install x2goagent locally as root first and focus on adapting x2goserver.
Thanks for this hint. Maybe I still need a bit more. What does actually happen when x2goclient connects to the server machine? Is it calling x2goagent and x2goagent then starts x2goserver? Could you point me to the code in x2goclient that does the first steps? What is currently not so clear to me is, in which order and what programs are started until I have a running connection.
Of course, I'd like to know the nasty details.
Ralf