Author Topic: Support for CodeBlocks in CMake  (Read 46206 times)

alex.neundorf

  • Guest
Support for CodeBlocks in CMake
« on: August 27, 2007, 12:56:18 am »
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

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Support for CodeBlocks in CMake
« Reply #1 on: August 27, 2007, 08:32:58 pm »
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.

Offline Game_Ender

  • Lives here!
  • ****
  • Posts: 551
Re: Support for CodeBlocks in CMake
« Reply #2 on: August 27, 2007, 08:34:55 pm »
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

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #3 on: August 27, 2007, 08:57:04 pm »
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

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #4 on: August 27, 2007, 09:02:37 pm »
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
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #5 on: August 27, 2007, 09:23:11 pm »
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.



Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #6 on: August 27, 2007, 09:37:30 pm »
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. :)
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #7 on: August 27, 2007, 09:47:25 pm »
> 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

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #8 on: August 28, 2007, 04:20:29 pm »
> 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
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #9 on: August 28, 2007, 04:37:56 pm »
> 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

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Support for CodeBlocks in CMake
« Reply #10 on: August 28, 2007, 04:56:33 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Support for CodeBlocks in CMake
« Reply #11 on: August 28, 2007, 05:02:55 pm »
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.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Support for CodeBlocks in CMake
« Reply #12 on: August 28, 2007, 05:12:58 pm »
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.
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #13 on: August 28, 2007, 05:15:39 pm »
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

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Support for CodeBlocks in CMake
« Reply #14 on: August 28, 2007, 05:23:13 pm »
Quote
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.


Quote
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:
Quote
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.

Quote
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.
« Last Edit: August 28, 2007, 05:34:13 pm by thomas »
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #15 on: August 28, 2007, 05:44:56 pm »
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.
[/quote]

Well, you can write the software in such a way that it works with all these compilers :-)

Alex


Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #16 on: August 28, 2007, 06:40:01 pm »
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: ?

Let me complete the blanks. Word on the left before the colon is the Compiler id used in C::B.

arm-elf-gcc: GNU ARM GCC Compiler
avr-gcc: GNU AVR GCC Compiler
msvc: MSVC 6
msvctk: Microsoft Visual C++ Toolkit 2003
ow: OpenWatcom
Be a part of the solution, not a part of the problem.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Support for CodeBlocks in CMake
« Reply #17 on: August 28, 2007, 06:47:01 pm »
Quote
I think I can add the include directories at target level.
How does the xml look for that ?

You could have a look at the wiki for a detailed description of our file formats.
Be patient!
This bug will be fixed soon...

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #18 on: August 28, 2007, 08:22:10 pm »
As I already noted, the generator creates makefiles + CodeBlocks project files.
The makefiles can be for GNU mingw make, cygwin make, MS nmake, Borland make, Watcom make.
This is (except cygwin) independent from the compiler, i.e. the GNU make Makefiles can use gcc or any of the MS cl 6/7/8 compilers, and the nmake makefiles can use cl or gcc or whatever.

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).

Alex



Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #19 on: August 28, 2007, 08:32:44 pm »
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).

The compiler name is necessary to launch the appropriate make utility. So if you put msvc there and then create a MinGW makefile, then C::B will instruct nmake to read that makefile. Nmake will fail to read the syntax and the compilation would fail. So this compiler id is necessary for successful compilation.
« Last Edit: August 28, 2007, 08:34:37 pm by Biplab »
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #20 on: August 28, 2007, 08:44:54 pm »
But there is also the MakeCommands section, where I can specify the commands. cmake can generate the correct gnu make/nmake/etc. commands there, so it shouldn't happen that a wrong make is called.
(you can e.g. use GNU make together with cl to get parallel builds with cl, which nmake can't do).

Maybe this is also used for the parsing of the output to detect warnings and errors ?


Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #21 on: August 28, 2007, 09:01:47 pm »
Yes you can specify the command. But if unspecified $make variable would be replaced by the make utility of the current compiler.
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #22 on: August 29, 2007, 04:18:13 pm »
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).

Also for targets of type library the toolbar offers "run" and "build and run" actions.

"Abort" didn't cancel the build (svn from two days ago).

Alex

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #23 on: August 29, 2007, 07:51:22 pm »
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.

But a bug has been introduced. The compiler id for MinGW on Windows is gcc Not mingw. :)

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.

You've found a bug. :)

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).

There is a Tab named "Build Log". Please look into it for errors. I guess it complained that -
Quote
"Project - Hello" uses an invalid compiler [YOUR ANSWER IS ALREADY THERE. SEARCH THE FORUMS!]. Skipping...
Nothing to be done.
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #24 on: August 29, 2007, 08:12:24 pm »
In a previous posing Thomas  said about mingw:

> 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.

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 ?

Alex

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #25 on: August 29, 2007, 08:22:44 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 ?

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 &quot;C:/Software/CMake/a bin/Makefile&quot; Hello" />

This should be executed properly.
« Last Edit: August 29, 2007, 08:41:37 pm by Biplab »
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #26 on: August 29, 2007, 09:20:37 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 ?

mingw is not used in any other case.

Ok.

Edit 1:

You can put some quote around the file path. E.g.,

Code
<Build command="C:/MinGW/bin/mingw32-make.exe -f &quot;C:/Software/CMake/a bin/Makefile&quot; Hello" />

This should be executed properly.

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

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #27 on: August 29, 2007, 09:41:46 pm »
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

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #28 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.

Alex

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #29 on: August 30, 2007, 05:43:14 pm »
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-
Quote
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
Be a part of the solution, not a part of the problem.

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #30 on: August 31, 2007, 03:47:15 pm »
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-
Quote
g++ -o foo -c foo.cpp

I don't understand.
I can supply a make command for building single files with the CompileFile tag. CB uses that command, it also replaces $file with the location where it thinks the object file will be. But CMake puts these files in a different location and the targets for building the object files are not available in all directories, only in the makefile for the target to which the object file belongs.

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
or
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

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.

One project per target ?
I'll try if I find the time.

But you may consider to have One Target per Directory and then these targets belong to a single Project.


No, I can't do that. CMake projects can put as many targets as they want in one directory, and CMake has to create working makefiles/project files for whatever they do.

Alex

Offline Biplab

  • Developer
  • Lives here!
  • *****
  • Posts: 1874
    • Biplab's Blog
Re: Support for CodeBlocks in CMake
« Reply #31 on: September 02, 2007, 08:03:32 pm »
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

Sorry for this late reply. You can discuss this with Yiannis.

Personally I dislike this idea. It would clutter the project file with n number of make commands for each source file.

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

Currently for make files, the object creation and output creation is Not handled by C::B. It just executes the makefile.
Be a part of the solution, not a part of the problem.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Support for CodeBlocks in CMake
« Reply #32 on: September 03, 2007, 11:19:33 am »
Quote
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
This is implemented:
<Unit filename="pumbalumba.tongalanga">
   <Option compile="1" />
</Unit>


However, I am not sure if this is really what you want to use... in any case, it is a cleaner (and more efficient for the project loader) to have the IDE compile files that it recognises as sources.

Quote
how to construct the name of the target for the object files and in which directories to execute them
<Target title="default">
   <Option output="\pumbalumba" prefix_auto="1" extension_auto="1" />
   <Option working_dir="cucucucu\cuuuuuaaaaa" />
   <Option object_output="fee\fei\fo\fum" />
   ...

This does not work?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

alex.neundorf

  • Guest
Re: Support for CodeBlocks in CMake
« Reply #33 on: September 18, 2007, 03:53:14 pm »
No, doesn't work. At least I am able to remove the .objs/ from the object path.

Now I get "make: *** No rule to make target `src dir/CMake/Source/cmDepends.o'.  Stop"
I would need just the filename, without the path:
make cmDepends.o, executed in the right directory.

How can I find out in which directory this was executed ?

Alex