Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Support for CodeBlocks in CMake
Biplab:
--- Quote from: alex.neundorf on August 29, 2007, 08:12:24 pm ---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 ?
--- End quote ---
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" />
--- End code ---
This should be executed properly.
alex.neundorf:
--- Quote from: Biplab on August 29, 2007, 08:22:44 pm ---
--- Quote from: alex.neundorf on August 29, 2007, 08:12:24 pm ---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 ?
--- End quote ---
mingw is not used in any other case.
--- End quote ---
Ok.
--- Quote from: Biplab on August 29, 2007, 08:22:44 pm ---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" />
--- End code ---
This should be executed properly.
--- End quote ---
Ok, committed.
The CB Debug tab has one red item:
ERROR: Plugin resource not found: libwxsmithlib.zip.
I guess I can ignore that ?
Alex
alex.neundorf:
I can't get "Build file" to work.
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.
Alex
alex.neundorf:
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.
Alex
Biplab:
--- Quote from: alex.neundorf on August 29, 2007, 09:20:37 pm ---The CB Debug tab has one red item:
ERROR: Plugin resource not found: libwxsmithlib.zip.
I guess I can ignore that ?
--- End quote ---
Yes you can ignore that. :)
--- Quote from: alex.neundorf on August 29, 2007, 09:41:46 pm ---I can't get "Build file" to work.
--- End quote ---
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-
--- Quote ---g++ -o foo -c foo.cpp
--- End quote ---
--- Quote from: alex.neundorf on August 29, 2007, 09:41:46 pm ---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.
--- End quote ---
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.
--- Quote from: alex.neundorf on August 29, 2007, 09:41:46 pm ---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.
--- End quote ---
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. :)
--- Quote from: alex.neundorf on August 29, 2007, 10:07:04 pm ---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.
--- End quote ---
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
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version