Code::Blocks
November 28, 2014, 04:59:35 am *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: The new Release 13.12 is out! You can download binaries for windows, mac and many major linux distros from  http://www.codeblocks.org/downloads/26 .
 
   Home   Help Search Login Register  :: WebsiteWiki  
Pages: [1] 2 3 4 5 6 7   Go Down
  Send this topic  |  Print  
Author Topic: cbp2make - makefile generation tool  (Read 62618 times)
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« on: November 13, 2010, 10:27:15 pm »

cbp2make is another standalone command-line tool to convert Code::Blocks projects to GNU makefiles.
Unlike previously appeared cbp2mak (v0.2) tool it does not require to be built for individual projects,
however, it is still in early stage of development and currently able to process only simple project files.
Hopefully, somebody will find this tool useful (http://sourceforge.net/projects/cbp2make).
I'm using CB constantly and going to support all or at least most of CB project/workspace features in this tool.
Any comments or suggestions are welcome.
Logged
xunxun
Almost regular
**
Offline Offline

Posts: 187



« Reply #1 on: November 14, 2010, 09:26:09 am »

That's very useful function, and you can refer to cbmakegen plugin.

http://forums.codeblocks.org/index.php/topic,6241.0.html
http://developer.berlios.de/projects/cbmakegen/
Logged

Regards,
xunxun
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #2 on: November 14, 2010, 12:57:01 pm »


Thank you, xunxun1982, I will refer to that.

Actually, I've looked through the plugin code and it seems that I haven't missed too many features.
So I have to add few words on what cbp2make can do and what it cannot in the current state.
Pros.:
(+) reads .cbp file directly and does not require .depend file presence as well as CB presence.
(+) processes all targets and all virtual targets, "all" and "clean" targets are added by default
(+) supports two(three) of all types of targets: binary, static library, (dynamic library)
(+) generates individual makefile for every platform
(+) keeps toolchain configuration in local xml file
Cons.:
(-) doesn't know how to process .workspace files
(-) doesn't work when project has no targets
(-) other types of targets are not supported
(-) doesn't generate makefile rules for before-build and after-build commands
(-) makes no difference between platforms and generates makefiles for unix toolchains
(-) can't read CB toolchain configuration from CB profile due to tinyxml library limitations (CDATA sections).

Quote
Usage syntax:

        Generate makefile:
                cbp2make -in <project_file> [-cfg <configuration>] [-out <makefile>]
                cbp2make -list -in <project_file_list> [-cfg <configuration>]

        Manage toolchains:
                cbp2make --config
                cbp2make --config --add --default
                cbp2make --config --add -alias <toolchain> -cc <c_compiler> -cpp <c++_compiler> -ln <linker> -st <static_linker>
                cbp2make --config --remove -alias <toolchain>

        Common options:
                cbp2make --verbose      // show project information
                cbp2make --quiet        // hide all messages
                cbp2make --help         // display this message
Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #3 on: November 17, 2010, 02:33:38 am »

Update: (see rev.30)

  • Added support for Code::Blocks workspace files
  • Project and unit dependencies are taken into account via weights/priorities
  • Implemented "compile" and "link" flags for build units
  • Implemented external dependencies for targets
  • Implemented Before-build and After-build commands
  • Projects without targets are processed with "default" virtual target
  • Makefile names are made by appending ".mak" extension now, not by replacing input file extension.
  • Improved toolchain management (this feature is incomplete yet)

There's still a lot of work has to be done...
  • Windows/Mac platforms
  • Environment variables
  • Non-inclusive compiler/linker option relations
  • Working directories for targets
  • Resource compilers
  • Other types of targets
  • Other compilers from gcc collection
  • ...
Logged
oBFusCATed
Developer
Lives here!
*****
Offline Offline

Posts: 7741


« Reply #4 on: November 17, 2010, 08:57:10 am »

mirai: Do you have plans to make automake/autotools system generation?
Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #5 on: November 17, 2010, 08:56:20 pm »

mirai: Do you have plans to make automake/autotools system generation?

Honestly, I just haven't thought about creating that kind of build tool.
As far as I know, the autotools system is rather complicated and unfriendly one.
However, If there is an actual necessity to connect CB to automake/autotools system,
maybe it is a good idea to get concerned about developing such tool.
For the time being, I want to get makefile generation tool to production state
as soon as possible before I am forced to switch to something else...
Logged
xunxun
Almost regular
**
Offline Offline

Posts: 187



« Reply #6 on: November 18, 2010, 04:28:02 am »

I think you can add Linux makefile/Mingw makefile(make/mingw32-make) and Windows makefile(nmake) support.
Logged

Regards,
xunxun
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #7 on: November 19, 2010, 02:20:09 am »

I think you can add Linux makefile/Mingw makefile(make/mingw32-make) and Windows makefile(nmake) support.

That's what I'm actually planning (all but nmake, because there's a little different story with nmake, I may add nmake later).
Almost all of the time I'm developing and testing under Linux, so Windows part may not work for now.

Update: (see rev.35)
  • Improved platform and toolchain management
  • Implemented compiler and linker option relations
  • Working directories for targets (see macros.h TARGET_WDIR_ENABLED)
  • Commands-only targets
  • Support for fortran compilers (f77,f9x)
  • Extended object names (like foo.cpp.o vs foo.o)
  • Limited support for Windows/Mac platforms (untested yet)

.
Quote
Usage syntax:

        Generate makefile:
                cbp2make -in <project_file> [-cfg <configuration>] [-out <makefile>]
                         [-unix] [-windows] [-mac] [--all-os]
                cbp2make -list -in <project_file_list> [-cfg <configuration>]
                         [-unix] [-windows] [-mac] [--all-os]

        Manage toolchains:
                cbp2make --config
                cbp2make --config --add --default
                cbp2make --config --add -alias <toolchain> [-cc <c_compiler>]
                         [-cpp <c++_compiler>] [-ln <linker>] [-st <static_linker>]
                         [-ranlib <ranlib>] [-windres <windres>] [-make <make>]
                cbp2make --config --remove -alias <toolchain>

        Manage platforms:
                cbp2make --config [-unix|-windows|-mac] [-pwd <print_dir_command>]
                         [-cd <change_dir_command>] [-rm <remove_file_command>]
                         [-rmf <remove_file_forced>] [-rmd <remove_dir_command>]
                         [-tf <test_file_command>] [-td <test_dir_command>]
                         [-md <make_dir_command>] [-mdf <make_dir_forced>]

        Common options:
                cbp2make --verbose      // show project information
                cbp2make --quiet        // hide all messages
                cbp2make --help         // display this message


Now I'm gradually starting to switch from developing to testing and working on compatibility with Windows.
There are few things I had problems with.
One problem is working directories for targets. According to CB's wiki, one should change directory to target's
working directory before building it, but applying that to the CB projects results in discrepancy in expected paths
in build command sequence. What's wrong?
Another is calling resource compilers, processing of WX forms, etc. How does CB invokes this resource compiler stuff ?
There are also few other things to implement before full-scale testing, but I think they will be completed in the course of time.
« Last Edit: November 19, 2010, 11:49:04 am by mirai » Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #8 on: November 20, 2010, 03:46:44 pm »

Update: (see rev.37)

  • Moved Before-build and After-build commands to individual targets
  • Fixed dynamic library linking
  • Fixed makefile generation for project with multiple targets
  • Fixed makefile generation for workspaces
  • Fixed issues caused by wrong file paths or extensions

I tried to convert and build Code::Blocks IDE project and plug-ins workspace and it seems that it mostly worked out with couple of exceptions. (openSUSE 11.2 x86, gcc 4.4.x, wxWidgets 2.8.10, CodeBlocks 10.05)
1) Neither CB build system nor make tool could not link "codeblocks" executable leaving me with error message
" ../../devel/libwxscintilla.so: undefined reference to `sci2wx(char const*)' "
after everything else before final linkage went just fine.
2) Neither of build tools could not select correct "wxscintilla.h" out of system default and one from CB sources,
even with include directories given in right order, so I had to rename CB's version of wxscintilla.* files and change #include directives accordingly.

Please confirm if cbp2make really works in for unix version of CB IDE project or for any of your projects.
« Last Edit: November 20, 2010, 09:44:24 pm by mirai » Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #9 on: November 21, 2010, 02:00:51 pm »

Update: (see rev.38)

  • Fixed makefile generation for Windows platform
  • Switched Windows platform defaults to MinGW (32bit)

Now cbp2make works for my projects in Windows, but they are quite simple. I would be very grateful to everyone for testing this tool or for links to open source projects developed with CodeBlocks to test against them.
Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #10 on: November 23, 2010, 08:47:15 pm »

Update: (see rev.39)

  • Fixed misbehavior caused by missing configuration, now configuration file is created automatically.
  • Fixed missing commands for creation of output directory for object files of source files located in project root directory.
Logged
oBFusCATed
Developer
Lives here!
*****
Offline Offline

Posts: 7741


« Reply #11 on: November 23, 2010, 09:40:45 pm »

mirai: Do you use some version control system, because I couldn't find it in the project page on the sf.net?
Logged

<debugger plugin maintainer>
(most of the time I ignore long posts)
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #12 on: November 23, 2010, 10:15:45 pm »

mirai: Do you use some version control system, because I couldn't find it in the project page on the sf.net?
Yes, I use Git locally, but I don't publish the repository, generally because I don't feel strong reason to do so (at least now).
And, since Git has no true revision numbers, I use following naming scheme: "project-branch-revision",
where "revision" is simply `git log --pretty=format:'%h' | wc -w` expression evaluated while switched to that branch.
« Last Edit: November 23, 2010, 11:11:34 pm by mirai » Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #13 on: December 05, 2010, 03:28:27 am »

Update: (see rev.42)

  • Changed configuration lookup order. Previously is was: 1) "-cfg" parameter, 2) current directory; Now it is: 1) "-cfg" parameter, 2) home directory 3) current directory; The "--local" parameter overrides home directory lookup, and the "-cfg" parameter overrides "--local" parameter. Also, fixed issue with appearing of empty configuration name (".cfg" files) in certain cases.
  • Environment variables.
  • External dependencies for targets.

.
Logged
mirai
Advanced newcomer
*
Offline Offline

Posts: 90


« Reply #14 on: December 11, 2010, 05:16:39 pm »

Update: (see rev.53)

  • Added support for global compiler variables. The "--config" option now has one mandatory parameter which may be "toolchain", "platform" or "variable". Global compiler variables are added to configuration using the "--add" option, the two other mandatory options "-name" and "-value", and the two other options "-set" (default value is "default") and "-field" (default value is "base"). Removal of a variable is mostly alike, but setting both "-name" and "-field" options removes only user-added field, setting only "-name" option removes the whole variable and settings the "-set" option alone removes the entire variable set. Since "default" variable set cannot be deleted, removing it will only clear the variable set. Global compiler variables are basically translated into makefile variables without any additional checking for being correctly defined, recursive variable resolution is up to the make tool.
  • Implemented "flat objects" feature. The "--flat-objects" option simply disables hierarchical paths for objects (ex.: "dir1/dir2/file.o" becomes "file.o"), and the "--flat-objpath" option adds modified path as a prefix to the object file name (ex.: "dir1/dir2/file.o" becomes "dir1_dir2_file.o").
.
Quote
Usage syntax:

        Generate makefile:
                cbp2make -in <project_file> [-cfg <configuration>] [-out <makefile>]
                         [-unix] [-windows] [-mac] [--all-os] [--flat-objects] [--flat-objpath]
                cbp2make -list -in <project_file_list> [-cfg <configuration>]
                         [-unix] [-windows] [-mac] [--all-os] [--flat-objects] [--flat-objpath]

        Manage toolchains:
                cbp2make --config toolchain --add -alias <toolchain> [-cc <c_compiler>]
                         [-cpp <c++_compiler>] [-ln <linker>] [-st <static_linker>]
                         [-ranlib <ranlib>] [-windres <windres>] [-make <make>]
                cbp2make --config --remove -alias <toolchain>

        Manage platforms:
                cbp2make --config platform [-unix|-windows|-mac] [-pwd <print_dir_command>]
                         [-cd <change_dir_command>] [-rm <remove_file_command>]
                         [-rmf <remove_file_forced>] [-rmd <remove_dir_command>]
                         [-tf <test_file_command>] [-td <test_dir_command>]
                         [-md <make_dir_command>] [-mdf <make_dir_forced>]
                         [-make <default_make_tool>]

        Manage global compiler variables:
                cbp2make --config variable --add [-set <set_name>] -name <var_name>
                         [-desc <description>] [-field <field_name>] -value <var_value>
                cbp2make --config variable --remove [-set <set_name>] [-name <var_name>]
                         [-field <field_name>]

        Common options:
                cbp2make --local        // use configuration from current directory
                cbp2make --config show  //show configuration
                cbp2make --verbose      // show project information
                cbp2make --quiet        // hide all messages
                cbp2make --help         // display this message


Support for other compilers and non-GNU tools (nmake, etc.) with totally different command syntax will be added later.
« Last Edit: December 12, 2010, 09:04:08 am by mirai » Logged
Pages: [1] 2 3 4 5 6 7   Go Up
  Send this topic  |  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!