A question to those who must maintain a Linux version and a Windows versions application.

Do you tend to cross-compile from Linux or do you compile native (with separate projects) on each OS (Linux and Windows)?

Thanks
Brian

I compile native for linux, windows and Mac and cross-compile only for Android.

I use the same project unit for every system except Android.

Native where possible, but that's more habit than anything else.

Native, because of two reasons:
- Without the target system, the application cannot be tested thoroughly, and if one has the target system, why not build on it?
- Some dependencies (such as autogenerated code) need to be compiled on the target system. It could probably be done on a linux system as well, but same argument as above...

Projects are identical on both platforms though (except for a few ifdefs to access OS-specific functionality).

Native on Windows, cross-compile for Linux.

Brian wrote

Do you tend to cross-compile from Linux or do you compile native (with separate projects) on each OS (Linux and Windows)?

In my experience I found that having various VM's for each target works best. The least amount of hassle, and all VM's sync the source code from the same code repository and all can be compiled with the same command line.

In my case: fpc @extrafpc.cfg <project_name>

The extrafpc.cfg file contains all the settings I need for DEBUG and RELEASE builds.

Regards,
- Graeme -

Do you tend to cross-compile from Linux or do you compile native (with

separate projects) on each OS (Linux and Windows)?

Cross compile from Linux. I can use Wine to test Windows compatiblity and I don't have Windows anyway :D

Ewald wrote

- Without the target system, the application cannot be tested ..

This is true, only because remote debugging is not well supported.

In fact I sometimes to programs to be run on a headless system (e.g. a NAS) Here you can't install Lazarus, because you don't have a GUI.

You easily can install fpc and compile native, though.

So I ended up testing the software on a PC (as far as possible without the hardware) and finally compile it on the target system.

I did not bother to install the cross compiler (the problem here is not fpc itself, but the cross-libraries that are necessary link the project for the target system).

If I would be able to use Lazarus on the development system to remote-debug the target system, the effort to install the complete cross-compile infrastructure would be viable.

-Michael

A headless system can still map a GUI to a desktop computer using X, VNC, SSH etc.

Michael Schnell wrote

On 01/27/2015 10:27 PM, Ewald wrote: > - Without the target system, the application cannot be tested .. This is true, only because remote debugging is not well supported.

For remote debugging a target system is needed as well? So even if remote debugging would be easy-peasy, the part you quotes still stands: no target system: no decent testing.

In fact I sometimes to programs to be run on a headless system (e.g. a NAS) Here you can't install Lazarus, because you don't have a GUI.

[this might be an extremely silly proposition, please forgive me] Why don't you run lazarus through ssh? Or use vnc?

I believe you are saying that you would like to cross-compile and debug the system remotely (which, judging from your other posts, are mostly embedded platforms?), but due to difficulties/roadblocks you are forced to compile it natively and debug it on the target system.

Well, _if_ the cross-compilation works, why not just ssh in to the target system and run gdb there? Please forgive my ignorance as I do not know the exact details of your setup.

Ewald wrote

[this might be an extremely silly proposition, please forgive me] Why don't you run lazarus through ssh? Or use vnc?

The (small) target system does not have any graphic-related stuff like X, qt or gtk. So VNC, or remote X will not work.

Of course I can access a command line via SSH.

Well, _if_ the cross-compilation works, why not just ssh in to the target system and run gdb there?

Happily, in fact the client system is advanced enough to allow running the full gdb (not just gdb-server).

Of course this does work. And I did just this. But direct manual work on gdb is rather painful. That is why it would be great to use Lazarus for remote debugging.

To do this there are two ways:

1) (this is activated in Lazarus by default) using remote gdb on the server and have same access gdb-server on the client. Here I have not been able to find / compile the appropriate remote gdb / gdb-server pair for the ARM target.

2) (the code to do this is commented out in Lazarus and supposedly not decently working) accessing a full gdb on the client via SSH.

-Michael

Hello.

I do main development on Linux 64.

For Windows, i use wine on Linux 64, (fpc.exe 32/64 installed without problem) and compile the source via wine-fpc.exe.

The advantage is that you do not have to copy your source to a virtual machine or a other native Windows.
And you may test your exe too on the same system ;-)

Fred

-----
Many thanks ;-)

Thanks for all the suggestions.

I rather like Fred's method using Linux / Wine , and after getting it working under Wine , I would do an end test native on on a Windows PC.

You may also install Lazarus.exe via wine.
With the SeupLazarus.exe, it install fpc.exe too ;-)

-----
Many thanks ;-)