Easiest way to use one code::blocks project on windows and linux

[kzvr]

I am developing a gui application for both windows and linux. Rather than mess around with a rats nest of cross compiling, I have both a windows and linux OS available for development.

Ideally I would like to be able to develop on windows, with the required libraries etc included by code::blocks, save the project and all source files, and upload the entire project to my VCS.

Then on linux it would be as simple as using my VCS to grab the latest project, and editing within code::blocks. I could develop in parallel no matter what system I was using.

As far as I can tell, the easiest way to do this is to maintain Debug/Release build targets for both windows and linux, ie 4 build targets in total in the project. However, I noticed that in the project properties - > build options windows there are fields for platforms and targets. Are those fields for cross compilation? Or is there a way to use them for my ideal, parallel setup.

Thanks

[Monochron]

Sorry to bring this subject back up, but I am interested in getting this information as well.

I am mostly interested in which options within C::B would be the easiest to port between Linux and Windows.  My plan is to have C::B on my Linux box and on my Windows box and to go between the two to release different versions.  This is because some of my code will be OS specific.

Will I be able to copy/paste my files from Linux to Windows and compile them?  If so, which compilers should I use on each OS?
I was planning on using wxWidgets for its cross-platform design, is this a good idea?

Any info would be great.

[cacb]

These are interesting questions. I have a working setup for Windows and Linux more or less as described by kzvr.

The idea for me has been to write GUI applications that run natively on Windows and Linux. Probably the easiest route is using MINGW and gcc on windows and gcc on linux. I have however a slightly different setup with MSVC C++ compiler on Windows and gcc on Linux. This means I have 4 build targets per project (MSVC_Release, MSVC_Debug, GCC_Release, GCC_Debug). The reason for using MSVC is that I need to integrate with other code made with MSVC compiler by others. Also the MSVC debugger is very good (I am cheating since I don't debug within C::B on Windows, but simply launch Visual Studio from the C::B Tools menu when I need to debug).

Using GCC only on both platforms will give you fewer surprises, but using two entirely different compilers makes you aware of portability issues and improve the code quality overall. They are not many, but noticeable.

I am usually running the latest C::B Nightly binary on Windows, but building C::B myself under Kubuntu, this is quite easy using Jens Lodys ready made tarball at http://apt.jenslody.de/testing/pool/main/c/codeblocks/

One may use a Network disk which is mounted on both Windows and Linux. Using the Bazaar Version Control System, it is quite easy to check out local branches on Windows and Linux, and push the results back to synchronize (but don't use Windows NTFS file system for linux development, it causes issues with Bazaar). Alternatively you can use Bazaar on one platform only and synchronize source files over Samba using programs such as Komparator (Linux/KDE). I have tried both. Of course, you can use whatever version control system you like, but Bazaar seems to work just fine with me-

I think C::B is very well suited for this kind of development in parallel on two platforms. It works very well, and  for me it is the only way. I have 2 screens side by side, one Windows and one linux, and "synergy" software to share keyboard and mouse between the two. Going from C::B on one OS to C::B on the other OS  happens by moving the mouse only.

I made my own kind of "project wizard" to create C::B project files that are set up according to my preferences, using the 4 build targets described. The "Wizard" is not integrated in C::B, it simply is a program that creates the *.cbp file in the right place. This saves a lot of time to start something new. 

Also, one has to think of such issues as DLLs and shared objects. The way I am doing it, I have projects that are DLLs built with MSVC on Windows and *.so shared objects built with GCC on linux. To do that you have to understand how the different compilers export symbols from DLLs/shared objects, but once you do you just write and build your code (with C::B) under one OS, copy project and source files to the other OS and build, again in C::B.

So this is definitively doable in many different ways.