The CB Debug tab has one red item:
ERROR: Plugin resource not found: libwxsmithlib.zip.
I guess I can ignore that ?
Yes you can ignore that.
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-
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.
Rather you can create a target for each file and then one
Virtual-target to compile all the targets at once. Each target will have one file and one makefile.
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.
If you look at the C::B project file (for C::B),
CodeBlocks.cbp for Windows &
CodeBlocks-unix.cbp for *nixes, you'll get an idea about it. Here different targets are producing libraries, dlls, executables and all of them have different output file name and are created on different folders, too. But they belong to a single project.
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 confirm this bug. Thanks for pointing it and also providing the trace.
You may consider to upgrade to a latest nightly to avoid that missing file error.
Best Regards,
Biplab
