Team cross-platform development with Code::Blocks?

[rickg22]

Hi everyone... I know it's embarrassing for a C::B dev to ask this :oops:, but... 

How do you do cross-platform developing with C::B when one of the developers uses Windows and another uses GNU/Linux?

I have this project ( http://sayavideoeditor.sourceforge.net/ for the curious - volunteers welcome ;-) ) that I started in GNU/Linux, so the project build settings are linux-specific of course. So, what should my Windows teammate do so he's able to compile our application with C::B?

Should I keep two separate .cbps? And how to sync them efficiently whenever I add new files to the project?

Yiannis, what did you do with C::B to solve this problem? I never needed to ask.

Sincerely,
your friendly ex-dev Rick ;-)

[mandrav]

Yiannis, what did you do with C::B to solve this problem? I never needed to ask.

Well, for various reasons, we keep two separate .cbp files. But this obviously is a hassle (to keep in sync etc). One of the reasons is that when I started writing C::B (yes, alone at the start there was no script generation tool to generate C::B project files, obviously :lol:.

Anyway, things have changed since those times and now there are at least a couple of such tools that support C::B project files generation.

I think CMake supports it albeit partially: it generates a normal Makefile and creates a C::B project that uses this Makefile. Not the best of options but one certainly worth considering .
Of course, things could very well have changed on this front since I last checked it out. If someone knows more about this, please share.

The tool that I 've found supports C::B almost fully and generates native C::B projects is Premake (pick version 3.6, don't go for the 4.x branch). I have first hand experience with this tool and I use it for many other projects of mine. I would definitely recommend this .

Now wait for anyone else having pearls of wisdom to share...

[rickg22]

Still no help....

Hey how about this: A feature called "Import files from another project" so that the files and targets get added, but the project build options remain the same?

Can it be done?

[Deschamps]

Maybe I haven't understand the question, but... Why don't simply define different build targets (for windows and Linux platforms) using the same .cbp? Even (depending of your project), if you are developing wxWidgets apps and the developers using Windows can use the wx-config port, then maybe you could use exactly the same target (and the same files, therefore) in both platforms.

Regards.

[JGM]

Also virtual targets may help organize, one virtual target for windows and other for unix systems. And inside each virtual target the release and debug versions of each platforms.

[rickg22]

Great. I get the right answer now that I managed to use scripting hacks to get it working. Go figure.

But it's a much cleaner solution, so I'll use JGM's suggestion. Thanks a lot, man!

Edit: It didn't work - I expected the virtual targets to also have compiler and linker options. I think C::B really needs either a "platform" level above the targets, or an additional flag on project/target settings that tells it to which platforms a setting applies.

This would make cross-platform devs' life much easier.

In any case, thanks everyone!

[rickg22]

Here's my solution!

I hope this can become the default wxwidgets monolithic-dll project for Code::Blocks.

From my blog:

Example: In your project settings:
Under "Compiler settings", "other options":

Code

[[if (PLATFORM == PLATFORM_MSW) print(_T("-mthreads -D__GNUWIN32__ -D__WXMSW__"));;]]
`wx-config --cflags`

(Note: The double ;; at the end is a workaround a scripting bug)
As you can see, the one-line script is pretty much like C. the _T must have been incorporated for wxWidgets compatibility. In any case, Notice the compilation string: -mthreads, -D__GNUWIN32__ and -D__WXMSW__. The -D is a compiler define. I tried to add scripting to the #defines, but that didn't work, so I had to add them on the compiler command line.

The wx-config part is for Linux. I've found that experimentally, having this option in the project doesn't affect compilation under Windows.

The same can be done with the linker. Under Linker settings, other linker options:

Code

[[if (PLATFORM == PLATFORM_MSW) print(_T("-mthreads -lwxmsw28u -lintl.dll"));;]]
`wx-config --libs`

Here I tell the linker to link two windows-only libraries: libwxmsw28u.a, and libintl.dll.a (libintl is used for internationalization). For posix environments (OS X or GNU/Linux), the backticked expressions are more than enough, but you could do the same with "if (PLATFORM != PLATFORM_MSW).

Under search directories, I add both the Windows and posix directories.

Compiler search dirs:

Code

$(#wx.include)
$(#wx)/contrib/include
$(#wx)/lib/gcc_dll/mswu

Linker search dirs:

Code

$(#wx)/lib/gcc_dll

Resource Compiler search dirs:

Code

$(#wx.include)
$(#wx)/lib/gcc_dll/mswu

With this simple settings, you won't require having two different projects, one for GNU/Linux or Mac OS, and another for Windows.

[killerbot]

H Rick,

I would also like 1 project file for both platforms. I do that already and I edit my project files manually, that way I have 4 targets (when creating an wx application ) :
 * Debug
 * Release
 * Win-Debug
 * Win-Release
Where the first 2 are set to be only for linux/mac platform, and the last 2 for the windows platform.
To be honest I prefer this setup since your solution with the #wx will cause me either :
 * to click a way at least 6 or more time the dialog that wants #wx to be defined (fixed a bug about this last week)
 * define that #wx, and as such I have to find out where it is on linux, where the cool wxconfig just makes not care about where it is

Plus In my setup each target puts it objects files and exe binary in different directories [most probably you can make this work with the script] so when you the project directory from one platform to another and some objects are still in place you won't get any strange compile or link errors.

So I would prefer (once asked the script project guru) to have a project wizard which creates the 4 targets, when done automatically I think I will be much clearer to the user and who knows what kind of defines might need to be added later on in platform a but not in platform b [you would always have to start scripting] or when you create projects where on platform a you need a special file A and on platform b you should not use file A but file B. Will be harder to maintain.

For *simple* projects (that stay simple) I think your suggestion might be sufficient, except from the #wx. That #wx should only be there in case of windows (unless in the wizard you specified you want to use it on any platform, but linux is the accepted wx-config way).

[Biplab]

So I would prefer (once asked the script project guru) to have a project wizard which creates the 4 targets, when done automatically I think I will be much clearer to the user and who knows what kind of defines might need to be added later on in platform a but not in platform b [you would always have to start scripting] or when you create projects where on platform a you need a special file A and on platform b you should not use file A but file B. Will be harder to maintain.

Sorry for the delay. But unfortunately I don't get much time to code nowadays. I am redesigning the wizard to some extent. This is how it looks right now.



But the coding is not complete yet.

[tuXXX]

I think, such crossplatform IDE as C::B defenitely NEED support of many platforms in ONE project...

Please, explain me, how to add new build targets in C::B project (not manually, but automatically through menus...)
I need, for ex, DebugLinux, ReleaseLinux, DebugWindows, ReleaseWindows and etc... targets...

PS I using wxWidgets library

ADDED:
I found how to create different targets... Project->Properties->Build targets and Add/Duplicate ...
But I found that in .cbp we have only one set of compiler options, and they incompatible on different platforms!
Please, help me, how to put two sets of compiler options in ONE project???
One for windows and one for Linux and assign that options to correct build targets?..

[oBFusCATed]

Hello,
I use C::B for cross platform development too.
I use 1 project file and I define different targets for different platforms. This is very handy, because I don't have to add files to different projects and try to keep them in sync.
But this approach has some problems because of missing features in C::B:
1. If your project is split in one executable + many libraries, you can make 1 project to be one part(lib or exer) and you can put all projects in 1 workspace. But there isn't a mechanism to link targets from different projects to depend on each other. A dev can resolve this dependencies manually, but it is hard and not fun experience (I've a project with only one lib, with more the pain will grow).
2. There is a difference in the way the cbp file is saved between the C::B in linux and in C::B in windows: on linux all file paths in the project file are converted to the linux's style of paths (replacing all '\' to '/'), on windows happens the opposite ('/' are replaced with '\'). This is a problem if you keep the project in svn/cvs, because it makes tracking changes in the project file impossible. If someone adds a file in windows and commits, and then someone else changes something and commits you get the whole project file to be different. There should be some kind of convention about this. You should choose on of the two ways of representing paths and stick to it for the file representation, and do the conversion on loading/saving.

I hope this discussion will continue, and will lead to the improvement of C::B for cross-platform development

Best regards,
Teodor

[oBFusCATed]

ADDED:
I found how to create different targets... Project->Properties->Build targets and Add/Duplicate ...
But I found that in .cbp we have only one set of compiler options, and they incompatible on different platforms!
Please, help me, how to put two sets of compiler options in ONE project???
One for windows and one for Linux and assign that options to correct build targets?..

You have different compiler options for every target (double click the target in the project -> properties (I don't have C::B in front of me so I could have written menu names wrong) or project->build target)
You also have a root target, where you can choose common options for all targets.
Click here and there and you'll get the idea. Also enable the full command line option in 'Settings -> compiler and debugger -> other -> something about output -> full command line'. This way you can see what options are directed to the compiler.

The root/default target reminds me of problem with it:
I have targets which use the gcc compiler and targets which use the vc7.1 compiler. If I set some global define in the root target, where for example the compiler is set to gcc, and then try to compile a target which uses the vc compiler the build fails. The reason is that the define options are formatted the gcc way: -Ddefine1 -Ddefine2, not the vc way: /Ddefine1 /Ddefine2
I'm not sure that this problem is solvable in the generic way... I've solved it by removing the global defines ...

[tuXXX]

Oh, big thanks to oBFusCATed =)
I found it! Project->Properties->Build targets->Platforms
If I choose not all platforms (as default), but one platform, such as only Windows or only Linux, code::blocks adds compiler options for each target configuration in .cbp file (I needed that)! ^_^

BUT... unfortunately, I need additional _manual_ editings of .cbp file to get all this work fine...
Who can add this vital functionality "multiplatform in one .cpb" in next release of CodeBlocks?

[oBFusCATed]

What do you need to edit manually? I've never touched the project file with a text editor to edit it ...

[MortenMacFly]

BUT... unfortunately, I need additional _manual_ editings of .cbp file to get all this work fine...

Huh? I don't get this. ALL parameters in a project file are configurable via the project / target settings. What exactly do you modify in the cbp file by hand?