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.
> 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).
Which compilers (with which names) are supported ?Depends on what compiler plugins are enabled (included in compilation). Usually these are at least:
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:
<Target title="my_target">
[...]
<Compiler>
[...]
<Add directory="include\tinyxml" />
</Compiler>
<Linker>
[...]
<Add directory="lib\tinyxml" />
</Linker>
</Target>
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:
[...]
<Project>
<Extensions>
<code_completion>
<search_path add="include/tinxml" />
</code_completion>
</Extensions>
</Project>
bcc: BorlandWhich 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. ;-)
I guess the directories in the compiler section are used for the autocompletion.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.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 purpose have the directories in the linker section ?
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.
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.
tcc: ?Tiny C Compiler. Very cool thing, but realistically it's probably of little or no significance.
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: ?
I think I can add the include directories at target level.
How does the xml look for that ?
For which purpose is the compiler option in the project file used ?
I mean, it is really the compiler, not the makefile ? So if I put "msvc" there and have cmake create mingw makefiles for cl it should be correct ?
(I think then there is no difference between version 6, 7 and 8 for the makefiles).
Ok, I committed some changes to the codeblocks generator.
It doesn't hardcode gcc anymore, it puts the include dirs for every target in the project file, it supports the different target types of codeblocks.
One question:
-what is the correct way to put a make command with a path with spaces in the project file ?
The following doesn't work:
<Build command="/usr/bin/make -f /home/alex/cmake/build\ dir/build-cb/Source/Makefile cmake" />
Putting \"the path\" in the project file worked worse, then CB couldn't load the project.
And some issues which are more feature requests/bugs:
Related: when CB loaded the project, it said there were errors, I should check the log file. Where is the log file ? (would be nice if the dialog would tell me where the log file is).
"Project - Hello" uses an invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!]. Skipping...
Nothing to be done.
So mingw gcc is called "gcc". Is mingw used in any other case ?
I have my sources here in "~/src dir/blah" and build always in "~/build dir/blah", so I always get the space related errors. So there is currently no way to quote/escape this properly for CB ?
<Build command="C:/MinGW/bin/mingw32-make.exe -f "C:/Software/CMake/a bin/Makefile" Hello" />
So mingw gcc is called "gcc". Is mingw used in any other case ?
I have my sources here in "~/src dir/blah" and build always in "~/build dir/blah", so I always get the space related errors. So there is currently no way to quote/escape this properly for CB ?
mingw is not used in any other case.
Edit 1:
You can put some quote around the file path. E.g.,Code<Build command="C:/MinGW/bin/mingw32-make.exe -f "C:/Software/CMake/a bin/Makefile" Hello" />
This should be executed properly.
The CB Debug tab has one red item:
ERROR: Plugin resource not found: libwxsmithlib.zip.
I guess I can ignore that ?
I can't get "Build file" to work.
g++ -o foo -c foo.cpp
To build a file I need to know the following:
-the path to the source file
-for which target the file is built
$file seems to be a path to the object file, and since CodeBlocks doesn't know where cmake puts the object files, this path is wrong.
I see two options:
either it should be possible to put the make command for a single file inside the <unit filename+...> block
or
add something like $sourcefile, so that I get the full path to the source file and in the make command for "build file" I can run some script which takes this path, computes the path of the object file and call make itself.
Then I didn't see a way to assign sourcefiles to targets, which I would actually need.
The project is organized like this:
one project is created, which contains targets for all executables/libraries within the source tree. No workspace is created (since all targets are already in the one project).
It would also be possible to create one project per target and then have one workspace which includes all projects. The only problem is that cmake targets like clean or install are not per-project, but per-directory, and there can be multiple targets in one directory. This would also make the build-file easier, since the directory is known.
It would also be possible to create one project per directory which has at least one target, and then one workspace which contains all projects. But then again this would give quite strange projectnames...
What do you think would be a good approach ?
Currently I have e.g. for the cmake tree one project "cmake" which has many targets (cmake, ccmake, ctest, cpack) and the source files are not assigned to one of these targets.
In svn revision 3938 there is a bug with relative paths to project files:
If I do that:
~/cmake/build dir/build-cb$ codeblocks Utilities/cmcurl/LIBCURL.cbp
CB loads the project, but complains "Project file doesn"t exist".
strace shows:
stat64("/home/alex/cmake/build dir/build-cb/Utilities/cmcurl/Utilities/cmcurl/LIBCURL.cbp", 0xbfa11d64) = -1 ENOENT
It works if I start it with the full path to the project file and if I start it from the same directory where the project file is located:
~/cmake/build dir/build-cb/Utilities/cmcurl$ codeblocks LIBCURL.cbp
So I guess if the path is no absolute path, it takes somewhere the location of the loaded project file and appends the relative path (which CB probably thinks it's just the filename) to it, so it ends up with the duplicated subdir.
I can't get "Build file" to work.
You're right. To compile a single file, it requires a project to be defined.
Because CMake is generating makefiles to be compiled with C::B, I don't see a way to compile a single file of any project. Actually you can (I've never tried that), but C::B will supply default arguments in that case. So if the project has one file named foo.cpp it will be compiled as-Quoteg++ -o foo -c foo.cpp
The project is organized like this:
one project is created, which contains targets for all executables/libraries within the source tree. No workspace is created (since all targets are already in the one project).
It would also be possible to create one project per target and then have one workspace which includes all projects. The only problem is that cmake targets like clean or install are not per-project, but per-directory, and there can be multiple targets in one directory. This would also make the build-file easier, since the directory is known.
It would also be possible to create one project per directory which has at least one target, and then one workspace which contains all projects. But then again this would give quite strange projectnames...
What do you think would be a good approach ?
Currently I have e.g. for the cmake tree one project "cmake" which has many targets (cmake, ccmake, ctest, cpack) and the source files are not assigned to one of these targets.
I prefer the second approach as it suits CMake requirement.
But you may consider to have One Target per Directory and then these targets belong to a single Project.
I need one of two things from CB to make this work:
1) make it possible to assign a CompileFile tag to every file in the <Unit> tag
2) make it possible to somehow tell CB how to construct the name of the target for the object files and in which directories to execute them. For cmake this is
make -f <path to directory for the target>/Makefile <filename>.o
I need one of two things from CB to make this work:This is implemented:
1) make it possible to assign a CompileFile tag to every file in the <Unit> tag
how to construct the name of the target for the object files and in which directories to execute them<Target title="default">