Support for CodeBlocks in CMake

[alex.neundorf]

Hi,

since a few weeks CMake, an open source cross platform buildsystem, has basic support for CodeBlocks projects. CMake is increasingly used by many open source projects, among them KDE4, PlPlot, OpenWengo, ChickenScheme and many others. With CMake you write one cmake script and then it generates for you Makefiles (GNU make, nmake, borland make, cygwin make, mingw), on Windows MSVC project files (from 6.0 to current), on Apple projects for XCode, under Unix projects for KDevelop3 and on all platforms project files for Eclipse.

I added basic support for generating CodeBlocks projects, so if a project uses cmake as its buildsystem, you can immediately start working on it with CodeBlocks without having to manually import a project or something.

Now the issue is, it is just quite basic support, since I don't use CodeBlocks myself (but with support for CodeBlocks I'd consider cmake complete in this regard) it would be nice if somebody who actually uses CB could test the CodeBlocks project generator and ideally make it work reliably.
CodeBlocks support is in CMake cvs (http://www.cmake.org/HTML/Download.html).

You can also reach me via neundorf (AT) kde (DOT) org.

Bye
Alex

[Game_Ender]

No guarantee's but I have a Scons based project that I have been wanting to try CMake on.  If I get the chance I will try the Eclipse and Code Blocks generators.

[Game_Ender]

Oh and while I have your attention, what is the standard way to get header files to show up in CMake generated projects?

[alex.neundorf]

Add the header to the list of sources.
(the kdevelop generator also checks automatically if there is a <dir>/foo.h if a <dir>/foo.cpp is used and adds it if found)

Alex

[Biplab]

Hi Alex,

I have few questions.

1. Does the latest release (2.4.7) have this feature? If not, can I get a binary build for testing? (Please note that I've rarely used CMake)
2. Which source file is exporting C::B project? I've downloaded the source from CVS, but I can't find it out.

Thanks,

Biplab

[alex.neundorf]

No, it's not yet released yet, if it gets enough testing and fixes it will be in CMake 2.6.0.
The file is Source/cmExtraCodeBlocksGenerator.cxx.
Currently there are no nightly snapshots to download.
For which platform do you need it ?

Building cmake on any UNIX is easy, on Windows you need to install a binary release of cmake (e.g. 2.4.7) and then configure the cmake from cvs with this one.

[Biplab]

No, it's not yet released yet, if it gets enough testing and fixes it will be in CMake 2.6.0.
The file is Source/cmExtraCodeBlocksGenerator.cxx.
Currently there are no nightly snapshots to download.
For which platform do you need it ?

Building cmake on any UNIX is easy, on Windows you need to install a binary release of cmake (e.g. 2.4.7) and then configure the cmake from cvs with this one.

Thanks Alex. I found the file.

I'd try to build a Windows Executable. Otherwise I'll request you for a build.

Had a quick look at the source.
1. Compiler is hard-coded to GCC.
2. Compiler vars of source files are not exported. (Though this may not be necessary for C/C++ header/sources)

I'll post my feedback later. It's late night here and now I'll sleep.

[alex.neundorf]

> Had a quick look at the source.
> 1. Compiler is hard-coded to GCC.

Yes. I tested only with gcc on Linux, that's also the reason why under Windows right now only the MinGW makefile generator is enabled. CMake supports also MS nmake, Borland make and MSYS and cygwin Makefiles, they should probably work too if CodeBlocks can handle the slight differences.

> 2. Compiler vars of source files are not exported. (Though this may not be necessary for C/C++
> header/sources)

What does that mean ?

The project generator work so that it creates makefiles accompanied by CodeBlocks projects for custom makefile based projects, completely set up with all available targets, source files etc. This is the same way as it is done for the KDevelop and Eclipse project generators in CMake.
Are the include directories required, i.e. does CodeBlocks do autocompletion where they would be needed ?
In theory it would also be possible to write a project generator for the native CodeBlocks build system, but this requires several orders of magnitude more work (and that there is no real CodeBlocks release doesn"t make it easier).

Alex

[Biplab]

> Had a quick look at the source.
> 1. Compiler is hard-coded to GCC.

Yes. I tested only with gcc on Linux, that's also the reason why under Windows right now only the MinGW makefile generator is enabled. CMake supports also MS nmake, Borland make and MSYS and cygwin Makefiles, they should probably work too if CodeBlocks can handle the slight differences.

Code::Blocks identifies the Compilers from the project file. So if an appropriate compiler name (GCC = gcc, Borland = bcc, MSVC 6 = msvc, etc) is provided, it can use that one.

> 2. Compiler vars of source files are not exported. (Though this may not be necessary for C/C++
> header/sources)

What does that mean ?

These are used by Compiler plugin to prepare appropriate command. They are assigned automatically by C::B based on file extensions. E.g., CC for C files. As CMake doesn't generate a native project, this can be ignored.

The project generator work so that it creates makefiles accompanied by CodeBlocks projects for custom makefile based projects, completely set up with all available targets, source files etc. This is the same way as it is done for the KDevelop and Eclipse project generators in CMake.
Are the include directories required, i.e. does CodeBlocks do autocompletion where they would be needed ?

For auto-completion, it is necessary to have the additional include directories to be added at Project level or Target level.

In theory it would also be possible to write a project generator for the native CodeBlocks build system, but this requires several orders of magnitude more work (and that there is no real CodeBlocks release doesn"t make it easier).

I'm unable to give any idea about next release. But the file format will not be changed drastically.

Best Regards,

Biplab

[alex.neundorf]

> Code::Blocks identifies the Compilers from the project file. So if an appropriate compiler name (GCC = gcc,
> Borland = bcc, MSVC 6 = msvc, etc) is provided, it can use that one.

Which compilers (with which names) are supported ?

> For auto-completion, it is necessary to have the additional include directories to be added at Project level or
> Target level.

So CodeBlocks does autocompletion ? Cool :-)
How does it do that ? Does it parse the code itself or does it use some tool ?
I think I can add the include directories at target level.
How does the xml look for that ?

Alex

[MortenMacFly]

Which compilers (with which names) are supported ?

Depends on what compiler plugins are enabled (included in compilation). Usually these are at least:
bcc, cygwin, dmc, dmd, gcc, gdc, gnuarm, gnuavr, icc, lcc, mingw, mscv, msvc8, ow, sdcc, tcc. ;-)

How does it do that ? Does it parse the code itself or does it use some tool ?

C::B utilises an own parser.

How does the xml look for that ?

Here is a snippet for includes at compiler and linker level:

Code

			<Target title="my_target">
				[...]
				<Compiler>
					[...]
					<Add directory="include\tinyxml" />
				</Compiler>
				<Linker>
					[...]
					<Add directory="lib\tinyxml" />
				</Linker>
			</Target>

I hope this helps,

With regards, Morten.

[MortenMacFly]

Here is a snippet for includes at compiler and linker level:
[...]

BTW: there is also a possibility at extension level. For CC (CodeCompletion) you can also add and/or modify the extension node as following:

Code

	<Project>
		<Extensions>
			<code_completion>
				<search_path add="include/tinxml" />
			</code_completion>
		</Extensions>
	</Project>

This is the same as if you would add those directories for CC *only* at project level. CC (if enabled within C::B) provides an appropriate GUI in the project settings.
With regards, Morten.

[thomas]

You might consider scripting Code::Blocks from CMake in the future. Not now, but keep the idea in the back of your head as an idea.

A while back, support for running scripts passed via the command line was added. This was done for the ReactOS build system, which is creating Code::Blocks project files from scratch using a complicated script and binutils.
Since this involves a lot of pain for the one particular person who has to maintain it, a better solution was sought by calling Code::Blocks with a script file telling it what to do, and letting the IDE do the actual work natively.

Unluckily, it doesn't quite work as I would like it to at the present time, since file/path handling in Code::Blocks is a nightmare. If you create a project programmatically, the resulting paths are all different than if you create the project from within the IDE, which kind of makes it all a bit pointless, as the resulting project is a mess
But one day, we will hopefully use an unambiguous, unified system to handle paths and files, and when all the different components stop doing their own thing, it should work.

Once it works reliably though, you will be able to tell Code::Blocks to make a project with the files you want, add the options you want, etc. without ever having to worry what the project file looks like, or that we might change it some day, you can't get it wrong.

[alex.neundorf]

Which compilers (with which names) are supported ?

Depends on what compiler plugins are enabled (included in compilation). Usually these are at least:
bcc, cygwin, dmc, dmd, gcc, gdc, gnuarm, gnuavr, icc, lcc, mingw, mscv, msvc8, ow, sdcc, tcc. ;-)

bcc: Borland
cygwin: cygwin gcc
dmc/dmd: is this the D compiler ?
gcc: gcc
gnuarm: gcc (where's there difference ?)
gnuavr: gcc (as above)
icc: Intel
lcc: lcc
mingw: gcc with windows paths or with msys paths ?
msvc: msvc 6 + 7 ?
msvc8: I guess msvc 8 :-)
ow: ?
sdcc: sdcc
tcc: ?

How does the xml look for that ?

Here is a snippet for includes at compiler and linker level:

Code

			<Target title="my_target">
				[...]
				<Compiler>
					[...]
					<Add directory="include\tinyxml" />
				</Compiler>
				<Linker>
					[...]
					<Add directory="lib\tinyxml" />
				</Linker>
			</Target>

I guess the directories in the compiler section are used for the autocompletion.
Which purpose have the directories in the linker section ?
Does this work also with full paths ?

Which slashes are required, backslashes on Windows and forward slashes on Unix ?

Thanks
Alex

[thomas]

I guess the directories in the compiler section are used for the autocompletion.
Which purpose have the directories in the linker section ?

Has nothing to do with code completion (primarily). Those are the include search dirs for the compiler and the object search dirs for the linker, respectively. Code completion uses the compiler's include dirs, too, but that is more incidential.

Which slashes are required, backslashes on Windows and forward slashes on Unix ?

Slashes should always work, they should be converted to backslashes if needed. You can of course use backslashes for Windows, but that makes it more complicated for you.

EDIT:

mingw: gcc with windows paths or with msys paths ?

gcc natively on Windows32, no MSYS or Cygwin or whatever involved. Funnily, it's simply called "gcc" on my system, but that might be a relict from long long long ago, since I'm still using the same config as years ago.

tcc: ?

Tiny C Compiler. Very cool thing, but realistically it's probably of little or no significance.
If you have gcc/mingw, then you are probably making 90% of your users happy already. The intel compiler is one-way-compatible to gcc, and neither bcc nor msvc/msvc8, nor dmc are available on non-Windows platforms, so I don't think one would want to use them for a portable project anyway.