pbcompilerc cross compilation (OS in priority and maybe arch?)

[Yann64]

With pbcompilerc using gcc as a backend, and most linux distributions having gcc cross compilers available, allowing to chose the target gcc would make for easy cross compilations, and almost transparent compiling to currently not supported OS/architecture provided they have Gtk/Qt (I am thinking of the BSDs, Haiku, etc...).

I know adaptations needs to be made on specific compiler constant regarding the os (#PB_OS, #PB_OS_FreeBSD, #PB_OS_Haiku, etc) and architecture (mostly indianness support would be tricky?), but is it something realistically doable (and could the community help in a way)?

[infratec]

And how do you test and debug your code

[Yann64]

And how do you test and debug your code

The exact same way I test/debug code with current Purebasic : the code is written/tested on main computer used as main dev environment which for me is Linux only. Cross compilation is to then have binaries/packages automatically generated for multiple architectures/OS from a single machine.
I will obviously test the binaries on target target OS but not necessarily on all architectures (I usually skip x86 as OS+PB should behave the same whatever the processor architecture).

I already have a script to generate binaries and packages for Linux x86, Linux 86_x64, Win x86 and Windows x86_64 from a single line of command (using wine for the windows binaries).
But this is not very clean and having the possibility to use official gcc cross compilers would be cleaner and on top of that would open access to more OS and more architectures.
Extra bonus would be the possibility to automate these multiple builds using things like GitHub actions/flows.
This is something which is commonly done in C, C++, go, etc.

[infratec]

You will run into big problems.

If a PB program works on windows or linux, it can fail on macOS and vice versa.
You always need a working PB IDE to debug such cases.
And for this you need a working OS.

So, at least for me, such a wish has a very very low priority.

[Fred]

It better for us to focus on real features than stuff like cross compiling. With virtual box and ssh it's really easy to manage automatically several OS compilation.

[moricode]

You will run into big problems.

If a PB program works on windows or linux, it can fail on macOS and vice versa.
You always need a working PB IDE to debug such cases.
And for this you need a working OS.

So, at least for me, such a wish has a very very low priority.

That means , the source code or the compiler is not real "cross platform" compatible if it can't compile and run for multiple different platforms without modification or even need to change program design .

[DarkDragon]

You will run into big problems.

If a PB program works on windows or linux, it can fail on macOS and vice versa.
You always need a working PB IDE to debug such cases.
And for this you need a working OS.

So, at least for me, such a wish has a very very low priority.

That means , the source code or the compiler is not real "cross platform" compatible if it can't compile and run for multiple different platforms without modification or even need to change program design .

Try it with C++ and you'll fall onto your nose as well. I made a Qt application a while back, ported it to Linux and Qt didn't implement the X protocol carefully enough, so it was all crap.

Every single cross platform front-end framework out there has this problem that it has to generalize things in a way that breaks things. Those who invented Win32API, Xlib, Carbon/Cocoa/UIKit thought usability ends with the end user, but indeed we should sue the shit out of them for making the world waste tons of energy and money on a non standardized API. Every OS nowadays has sockets with more or less the same commands, but for UI they were too stupid for sitting together.

I hate them from the bottom of my heart.