multi platform developement

[johu]

Hi, I'am a newbe. I found C::B seachting for a modern C++ IDE which allows to develop with different compilers (from MS to GNU) on different platforms. And C::B can do this not only with the GNU tools. But there is also the problem. If I have a workspace with projects compiled on Linux with GNU g++, put it in a repository, check it out on Windows and going on to compile it with MS compiler it does not work because the platform dependend informations are part of project description files *.cbp. It would be very useful if the platform dependend stuff would be separated from the "logical" informations. I can not find any discussion on such a topic. Any idea, hint, opinion?
Regards
J.

[mariocup]

Hi johu,

I would like to know what are the platform dependent information and then it will be easier to find an appropriate solution.

[stahta01]

Try looking at the wxSmithAui project in trunk or nightly build source. It has both Linux and Windows builds as separate targets of projects.

Tim S.

[johu]

Wow, very fast reaction. Thanks.
An idea from me you see in the following snippet of a cbp file where I see e fundamental configuration parameter as
<Option compiler="gcc" /> or  <Option compiler="msvctk" />.  These options are more than options. They include a
platform specification, very important.
The tags as Compiler and Linker could be subelements of a platform specification in a manner like this:
<Platform compiler="gcc>
     <Compiler>
            <Add option="-g -pthread" />
     </Compiler>
      <Linker>
         <Add library="someLib.a" />
      </Linker>
</Platform>
<Platform compiler="msvctk">
    <Compiler>
         <Add option="/Zi" />
     </Compiler>
     <Linker>
         <Add option="/DEBUG" />
         <Add library="someLib.lib" />
     </Linker>
</Platform>
Which set of options are actually in use is could be specified by the workspace or the environment dependent settings of C::B. These settings should only stored out off the stuff which I will check in into a repository.
I hope my intentions are clear. If not I ready for more discussion.
Regards
j.

[MortenMacFly]

These settings should only stored out off the stuff which I will check in into a repository.

Well - they are vital for successful compilation, aren't they? So if someone would checkout the project and try to compile it most likely would not work. I don't believe that makes sense.

However - are you aware that a project can have several targets and a target can be limited to specific platforms (meaning OS'es) in C::B? This way you can have the *right* target for your platform compiled depending on the platform where the build is triggered.

It's very easy:
- setup target "A" for platform "Unix"
- setup target "B" for platform "Windows"
- setup the required compiler for each target and all the options
- setup a virtual Target "All" that includes both targets

If you compile "All" on Unix only the Unix target will be compiled.
If you compile "All" on Windows only the Windows target will be compiled.

You just have one project and can even share same settings (e.g. equal defines for the platforms) by setting them up at project level.

IMHO that's all the flexibility you'll need and in fact it only works with saving all info in the project.

[johu]

Many thanks for the answer, the concept of "virtual target" is what I have in mind, a big point for C::B evaluating IDEs.
J.

[mariocup]

CodeBlocks offers also the possibility of using menu actions in scripts which can be assigned in a build target to control the generation of your project. Perhaps in some situation this helps too. Here an example:

Code

function SetBuildOptions(base)
{
        if(PLATFORM == PLATFORM_MSW)
        {
                local CompilerId = base.GetCompilerID();
                if(CompilerId.Matches(_T("gcc")))
                {
                        local CF = GetCompilerFactory();
                        if(!IsNull(CF))
                        {
                                local Version = CF.GetCompilerVersionString(CompilerId);
//                              LogDebug(Version);
                                // check how this string looks like and compare with 4.2.0
                                local bDoIt = (Version >= _T("4.2.0"));
                                if(bDoIt)
                                {
                                        base.AddCompilerOption(_T("-Wno-attributes"));
                                }
                        }
                }
        }
} // end of SetBuildOptions

The functions which can be accessed in a script are documented at the CB wiki page.

[MortenMacFly]

CodeBlocks offers also the possibility of using menu actions in scripts

Good point. Using build scripts you can achieve what I had mentioned with only one target. But you'll need to read yourself into scripting.