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

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.