Code::Blocks Forums

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

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

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

Quote from: xunxun1982 on November 14, 2010, 09:26:09 AM
That's very useful function, and you can refer to cbmakegen plugin.

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

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

QuoteUsage 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

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

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

Quote from: oBFusCATed on November 17, 2010, 08:57:10 AM
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...

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

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

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

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

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.

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.

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.
  

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

Quote from: oBFusCATed 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?

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.

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

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

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

Have you ever tried to compile this under windows (mingw)?

Quote from: user601 on January 11, 2011, 10:06:41 AM
Have you ever tried to compile this under windows (mingw)?

Yes, I did, but not the latest revison(s). Since I rewrote some platform-specific stuff after rev.38 and tested only Linux version, Windows part may become broken. Sorry for inconvenience, I will try fix Windows/MinGW issues as soon as I can.

Update: (see rev.58) Fixed problem with compiling Windows-specific code rewritten and broken after rev.39.

Quote from: mirai on January 20, 2011, 08:42:22 PM
Update: (see rev.58) Fixed problem with compiling Windows-specific code rewritten and broken after rev.39.

Crashes immediately on Windows if the cbp file is not present (was a typo in my command line).

Quote from: MortenMacFly on January 20, 2011, 09:26:23 PM

Quote from: mirai on January 20, 2011, 08:42:22 PM
Update: (see rev.58) Fixed problem with compiling Windows-specific code rewritten and broken after rev.39.

Crashes immediately on Windows if the cbp file is not present (was a typo in my command line).

..further information:
It crashes here:
result = getenv("HOME");
-> the assignment fails as getenv returns NULL. You cannot rely on envvars being present. The envvar HOME may exist on Windows but in many cases (as in mine) it does not. You probably want to use USERPROFILE instead. However, still you'll need to evaluate the return value getenv provides in any case. ;-)

Update: (see rev.60) Fixed errors in Windows build.

Argh... I've changed only a part of wrong code. There are macros to detect OS at compile time and switch blocks of code. In few places, an inexistent OS_WINDOWS macro was used instead of correct OS_WIN. That's my fault. Some other modules were also affected by this error.

Quote from: MortenMacFlyIt crashes here:
Code:
result = getenv("HOME");
-> the assignment fails as getenv returns NULL. You cannot rely on envvars being present. The envvar HOME may exist on Windows but in many cases (as in mine) it does not. You probably want to use USERPROFILE instead. However, still you'll need to evaluate the return value getenv provides in any case.

It was using "HOME" instead of "USERPROFILE" because the Unix version of code was compiled-in because of wrong macros. However, you are right, I have to insert some additional checks. I usually refer to Qt or WX for implementation of cross-platform stuff.

Update: (see rev.66)

• Implemented multi-line object file lists (use "--wrap-objects" option) which makes makefiles look more user- and cvs- friendly.
  
• Added options to configure f77/f90 compilers in toolchains.
  
• Added revision number to generated makefile header.
  
  Also, I started a complete rewrite of makefile generation code to prepare less hard-coded and more flexible infrastructure to reflect more CB build system features. cbp2make still misses good support of wide range of compilers and other build tools while CB can do so much more.

I found one problem, when use without --wrap-object then sections OBJ_DEBUG, OBJ_RELEASE are missing. Compiled tdm-gcc 4.5.1.

Quote from: Revan on March 15, 2011, 04:58:15 PM
I found one problem, when use without --wrap-object then sections OBJ_DEBUG, OBJ_RELEASE are missing. Compiled tdm-gcc 4.5.1.

Just fixed that, see rev.72.

p.s. I was really surprised when I found that these macros are missing when I tried to update some of my makefiles because they were just fine [not so] many revisions ago.

Quote from: mirai on March 15, 2011, 07:13:08 PM
because they were just fine [not so] many revisions ago.

If you renamed your targets that that's the reason.

Update: (see rev.80)

• Fixed commands-only type of targets so they no longer generate rules for object files and binary output, clean_* rules will not be generated for this type of targets either.
  
• Doxygen-style documentation is in progress...
  
  

Hi.

Just made a first test with cbp2make.
Generated makefile works but there is no .h dependencies management ?
Or I missed something ?

Thanks

Chris

Quote from: blinde on March 24, 2011, 11:15:29 AM
Just made a first test with cbp2make.
Generated makefile works but there is no .h dependencies management ?
Or I missed something ?

No, you haven't missed anything. I intentionally don't generate dependencies for non-compilable files. However, this may be wrong for some cases like forcing make to rebuild the project when a .h file changes. Just let me know if I'm really wrong at this point and I will fix the issue. I guess I have to (at least optionally) generate dependencies for all project files including non-compilable and/or especially treat C/C++ case with .h/.c pairs.

Quote from: mirai on March 24, 2011, 03:40:23 PM
I intentionally don't generate dependencies for non-compilable files.

Hum... Don't understand.
I have a test.c file.
test.c include test.h

test.c is a compilable file.

I think that there should be a dependency between test.c & test.h.

I don't know what is the purpose of cbp2make
1- it is just a workaround to temporary build a CB project in console mode.
So we accept the requirement of doing make clean; make all when I want to rebuild.
In this case I understand that we can forget dependencies.

2- cbp2make shoud really generate some makefile that are fully usable and that will replace the build made in CB
In this case, dependencies are mandatory (make clean; make all take 20mn on my project...)


Thanks

Chris

Quote from: blinde on March 24, 2011, 04:10:03 PM

Quote from: mirai on March 24, 2011, 03:40:23 PM
I intentionally don't generate dependencies for non-compilable files.

Hum... Don't understand.
I have a test.c file.
test.c include test.h
test.c is a compilable file.
I think that there should be a dependency between test.c & test.h.

test.h does not produce an object file, therefore, it is not a dependency for target binary.
However, it is a dependency of test.c ... and should be somehow taken into account.

Quote from: blinde on March 24, 2011, 04:10:03 PM
I don't know what is the purpose of cbp2make
1- it is just a workaround to temporary build a CB project in console mode.
So we accept the requirement of doing make clean; make all when I want to rebuild.
In this case I understand that we can forget dependencies.

The purpose is to build CB projects when CB is missing and cannot (should not) be installed by any means.
It is not just a workaround, even if it may seem so, because one of requirements is not depending on CB presence at all.

I think that it is possible to even make a complete build system out of cbp2make, i.e.,
to eliminate use of 'make' tool at all in some cases and run other build tools directly.

Quote from: blinde on March 24, 2011, 04:10:03 PM
2- cbp2make shoud really generate some makefile that are fully usable and that will replace the build made in CB
In this case, dependencies are mandatory (make clean; make all take 20mn on my project...)

Yes, that is my intention, i.e., fully usable makefiles.
Let me remind that cbp2make is still in alpha stage, and many necessary things are missing yet.

Never the less, thank you for paying attention to my efforts, I will try to fix this .h/.c problem.

One thing that bothers me about this kind of dependencies is that they are not contained in CB project.
I will probably have to scan source files and search for include directives and pay attention to other preprocessor directives... this may become a real problem.

Hi.

In my previous project, all the makefiles are home made.
And dependencies are fully managed.

The makefile can be called with clean / dep / all

dep, will automatically generates some <filename>.dep
it calls gcc with some special options and generate (e.g):

obj/VLX_NoiseMgr.o :   VLX_NoiseMgr.cpp ../../include/CSC_Utils/UTI_Error.h \
../../include/CSC_Utils/UTI_types.h \
/usr/local/include/wx-2.8/wx/wxprec.h \
/usr/local/include/wx-2.8/wx/defs.h \
/usr/local/include/wx-2.8/wx/platform.h \


one part of the makefile :


SrcSuf = .cpp
DepSuf = .dep
ObjSuf = .o

OBJDIR = obj

SRCS = $(SRC)
OBJF = $(patsubst %$(SrcSuf),$(OBJDIR)/%$(ObjSuf),$(SRCS))
DEPS = $(patsubst %$(SrcSuf),$(OBJDIR)/%$(DepSuf),$(SRCS))


DEBUGFLAGS = -Wall -g -O2 -D_NO_SHUTDOWN_
CFLAGS     = -D_REENTRANT `$(WXCONFIG) --cxxflags`

INCFLAGS = \
-I../../include/CSC_Spectro \

all:: $(DEPS) $(OBJF)

ifeq ($(MAKECMDGOALS),all)
include $(DEPS)
endif

$(OBJDIR)/%$(DepSuf): %$(SrcSuf)
@echo
@echo '------------------'
@echo -en "\033[30;47;1m"
@echo 'Making $< dependencies...'
@echo -en "\033[30;47;0m\n"
@if [ ! -d $(OBJDIR) ] ; then mkdir $(OBJDIR) ;fi ;
@$(CC) $(DEBUGFLAGS) $(CFLAGS) $(INCFLAGS) $(PROJFLAGS) -MM $< | sed 's/\($*\)\.o[ :]*/$(@D)\/\1.o :   /' >  $@ ;

$(OBJDIR)/%$(ObjSuf): %$(SrcSuf)
@echo '------------------'
@echo -en "\033[30;47;1m"
@echo 'Building $< ...'
@$(CC) $(DEBUGFLAGS) $(CFLAGS) $(INCFLAGS) $(PROJFLAGS) -c $< -o $@ ;
@echo -en "\033[30;47;0m\n"

clean::
@rm -rf $(OBJDIR)

print::
@echo "Dependances"
@echo $(DEPS)
@echo "Fichiers"
@echo $(OBJF)



mirai: look at the .depends file; also in the sources you can find a lib that generates these files.
blinde: please use code tags in order to make your posts more readable

Quote from: oBFusCATed on March 24, 2011, 06:28:06 PM
mirai: look at the .depends file; also in the sources you can find a lib that generates these files.

Thanks. I found "depslib" and spent some time digging in its code. According to what I discovered, the only thing that I really need is search for include directives and some magic about file paths to find header files. I think I don't need all of depslib as-is, since half of it is string-related stuff which I already have. And using a full-blown regexp library is an overkill for me here, so I decided to go with a couple of FSA for a couple of languages to parse sources. However, I did not found a piece of code in depslib for processing conditional compilation directives (#define, #ifdef, #endif, #else, etc) and more diffucult to manage #if directive since it may contain expressions. Ignoring these directives will/may result in false includes, and hence, false dependencies. So, my next question/problem is how (or what is the better way) to partially preprocess sources.

Search the forum, there are some discussion on the topic (and a very recent one in the Code Completion sub forum).

Quote from: oBFusCATed on March 25, 2011, 03:07:43 PM
Search the forum, there are some discussion on the topic (and a very recent one in the Code Completion sub forum).

Well, after reading the topic and code examples I gradually come to a conclusion that I should make some workaround or partial solution, but not the complete one needed for CC. Since the purpose is just to tell 'make' what files it should check for changes before turning a unit into an object file, the procedure of extracting dependencies could be simplified.
I suppose the following algorithm will do the job:

For every unit in a build target:

• 1) recursively scan for #include directives ignoring #ifdef-s and resolve paths of included files by searching these files in include path.
• 2) remove duplicate includes.
• 3) add all successfully found includes to dependencies of current unit's target.
• 4) forget includes that cannot be found or add them somewhere close to target as remarks.

This way missing dependencies won't trigger 'make' to complain about themselves, but all of existing dependencies will cause a rebuild of certain targets if necessary. There may be a small overhead caused by including false, but existing, dependencies, but this won't break anything.

So you'll rewrite depslib :lol:

Something like the following might help you get the dependencies that CB already sets up.


//----------------------------------------------------------------------------
void <yourclassname>::WriteMakDependencies(wxFFile& makeFile_fp)
// ----------------------------------------------------------------------------
{
    cbProject* prj = GetProjectManager()->GetActiveCBProject();
    if (not prj) return;

    wxFileName fn(GetProjectManager()->GetActiveCBProjectFilename());
    fn.SetExt(_T("depend"));
    wxString depsFilename = fn.GetFullPath();

    wxArrayString depsarr;
    wxString str;
    // Get array containing lines like "filename;dependfile;dependfile;"
    GetMakeDependencies( depsFilename, depsarr);
    if (depsarr.GetCount() == 0)
        return;

    for (size_t knt=0; knt < depsarr.GetCount(); ++knt)
    {
        wxArrayString adepLine = wxStringTokenize(depsarr[knt], wxT(";"));
        wxString shortFilename = adepLine[0].AfterLast(wxFILE_SEP_PATH);
        wxString filenameBase = shortFilename.BeforeLast(_T('.'));
        if ( not shortFilename.AfterLast(_T('.')).StartsWith(_T("c"))  )
            continue; //not a .cxx file
        if (adepLine.GetCount() > 1) do
        {   //source has dependencies
            wxString depstr = wxEmptyString;
            for (int j=1; j<(int)adepLine.GetCount(); ++j)
            { // append the dependecies;
                adepLine[j].Replace(_T("<"),_T(""));
                adepLine[j].Replace(_T(">"),_T(""));
                depstr.Append( adepLine[j] + _T(" "));
            }
            str.Printf( _T("%s.o: %s\n"), filenameBase.c_str(), depstr.c_str() );
            makeFile_fp.Write( CvtU2C(str), str.Length()); //name.o: dependent files
        }while(0);

        str.Printf( _T("%s.o: %s\n"), filenameBase.c_str(), shortFilename.c_str());
        makeFile_fp.Write( CvtU2C(str), str.Length());  //name.o: cxx filename
        str.Printf( _T("\t$(CC) -c $(CFLAGS) %s\n"), shortFilename.c_str() );
        makeFile_fp.Write( CvtU2C(str), str.Length());
    }

}//WriteMakDependencies
// ----------------------------------------------------------------------------
bool <yourclassname>::GetMakeDependencies(wxString& filepath, wxArrayString& depsarr )
// ----------------------------------------------------------------------------
{

    // Read .depend file into a wxArrayString consisting of lines of
    // sourcefilename;dependfilename;dependfilename;
    // sourcefilename;
    // sourcefilename;dependfilename; etc

    if (not ::wxFileExists(filepath))
        return false;
    wxString str;
FILE *f;
char buf[1024];
//int vmajor, vminor;
wxString h;
int n;
time_t timeval;

depsarr.Clear();

wxFFile file(filepath, _T("r"));

if ( not file.IsOpened() )
    return false;

    f = file.fp();

/* Skip magic */
fgets(buf, sizeof(buf), f);

while (fgets(buf, sizeof (buf), f))
{
buf[strlen(buf) - 1] = '\0'; /* zap newline */

if (!buf[0])
continue;

if (buf[0] == '\t')
{
str.Append( CvtC2U(buf+1) +_T(";"));
continue;
}

sscanf(buf, "%ld %n", &timeval, &n);
if ( not str.empty())
        {
            depsarr.Add(str);
        }
str = CvtC2U(buf+n) + _T(";");
}

    // last buffer
    if ( not str.empty())
    {
        depsarr.Add(str);
    }

//fclose(f); file closed by wxFFile
return true;
}


Quote from: Pecan on March 26, 2011, 03:58:07 PM
Something like the following might help you get the dependencies that CB already sets up.

I would need CB to make this work while one of major requirements is to avoid dependency from anything but .cbp/.workspace file.

p.s. Even just linking with CB SDK is not a solution, this would make me stuck with too large 3rd party code base.

Quote from: mirai on March 26, 2011, 05:46:15 PM

Quote from: Pecan on March 26, 2011, 03:58:07 PM
Something like the following might help you get the dependencies that CB already sets up.

I would need CB to make this work while one of major requirements is to avoid dependency from anything but .cbp/.workspace file.

It looks to me that depslib does not depend on Code::Blocks.

Tim S.

Quote from: stahta01 on March 26, 2011, 10:18:30 PM
It looks to me that depslib does not depend on Code::Blocks.

I meant that example of WX/CB-based code posted by Pecan.

p.s. Actually I'm already somewhere in the middle of implementing dependency management and will release as soon as it is ready.

Update: (see rev.91)

• Implemented dependency search for C/C++ source/header files. Use "--with-deps" option to generate makefile with those dependencies for every build unit.
  
• Added options to allow use of assembler.
  
• Fixed wrong working directory during makefile generation (it should have been changed to the directory of current project/workspace, but it wasn't).
  
• Few more docs for relatively stable part of code.
  
  The dependency management feature seem to work although current implementation is mostly experimental. Please, test it with your projects.
  p.s. There may be problem with extracting dependencies for projects created by CB on platform different from the one where makefile is created, e.g., extracting dependencies from project of Windows CB may fail in Unix (seems that some paths escaped required conversions).

Possible Bug:
A problem in compilation-

Quote
||=== cbp2make, Debug ===|
D:\Aditya\Downloads\cbp2make\cbp2make-stl-rev91\lib\stlfutils.cpp||In function 'CString GetCurrentDir()':
D:\Aditya\Downloads\cbp2make\cbp2make-stl-rev91\lib\stlfutils.cpp|261|error: 'getcwd' was not declared in this scope
D:\Aditya\Downloads\cbp2make\cbp2make-stl-rev91\lib\stlfutils.cpp||In function 'bool ChangeDir(const CString&)':
D:\Aditya\Downloads\cbp2make\cbp2make-stl-rev91\lib\stlfutils.cpp|271|error: 'chdir' was not declared in this scope
||=== Build finished: 2 errors, 0 warnings ===|

i Assume this was due to missing header file. Hence i added it
#include <unistd.h> in lib\stlfutils.h .It might interest you to know that This was on a windows xp system,with the default gnu gcc compiler. The current version downloaded today 14 April .

Quote from: adityagameprogrammer on April 14, 2011, 08:54:17 AM
Possible Bug:
i Assume this was due to missing header file. Hence i added it

Code Select Expand

#include <unistd.h> in

Code Select Expand

lib\stlfutils.h .It might interest you to know that This was on a windows xp system,with the default gnu gcc compiler. The current version downloaded today 14 April .

Hmm... this may happen in Windows if standard libc headers vary among systems (sorry, haven't tested it in Windows yet).
I will check this issue and upload an update ASAP.

Update: (see rev.93) Added missing headers.

Hi,

I love this program.  It has been very useful to me so far.

I am having one problem with it, though.  I have a project under Linux that includes a library where the version number is included in the name of the library.  (It is tcl8.4 if you're curious).  It appears that the program is assuming that the ".4" is a file extension, and so it tries to link without the "-l" flag, as it would when given an object file or the actual file name of a file to link.  Since it is really a library in the library path, the link step fails.

Any suggestions?

Thanks.

Quote from: ripcordjones on April 20, 2011, 11:38:14 PM
It appears that the program is assuming that the ".4" is a file extension, and so it tries to link without the "-l" flag, as it would when given an object file or the actual file name of a file to link. Since it is really a library in the library path, the link step fails.

Well, the program expects that libraries are named as GNU linker expects them to be, i.e., that a static library has file name "lib<something>.a" and corresponding linking option "-l<something>" without prefix "lib" and extension ".a", where <something> can be name or name plus version or anything else. If you have a library that does not follow this naming scheme, cbp2make may fail (and it actually does).

I can try to fix this by adding some logic to check if a library follows active naming scheme and change linking options accordingly.
Another solution is to rename that library file in the way that matches linker expectations or create a well-named symbolic link to the library inside your project tree or somewhere else withing linking path.

Quote from: mirai on April 22, 2011, 07:24:28 PM
Well, the program expects that libraries are named as GNU linker expects them to be, i.e., that a static library has file name "lib<something>.a" and corresponding linking option "-l<something>" without prefix "lib" and extension ".a", where <something> can be name or name plus version or anything else. If you have a library that does not follow this naming scheme, cbp2make may fail (and it actually does).

I can try to fix this by adding some logic to check if a library follows active naming scheme and change linking options accordingly.
Another solution is to rename that library file in the way that matches linker expectations or create a well-named symbolic link to the library inside your project tree or somewhere else withing linking path.

Thanks for the reply.  Just to clarify, the library is actually called libtcl8.4.a, but it's stored in the .cbp without the lib and .a, so the line in the .cbp looks like this
    <Add library="tcl8.4" />
but this gets put in the Makefile without the "-l"
    LIB = [... a bunch of libraries ...] -lrt -lz tcl8.4 -ldl

I can try some workarounds, but I thought you might want to know about it in case there are other libraries that use a similar naming scheme.

Quote from: ripcordjones on April 23, 2011, 12:58:17 AM
Thanks for the reply.  Just to clarify, the library is actually called libtcl8.4.a, but it's stored in the .cbp without the lib and .a, so the line in the .cbp looks like this
    <Add library="tcl8.4" />
but this gets put in the Makefile without the "-l"
    LIB = [... a bunch of libraries ...] -lrt -lz tcl8.4 -ldl

A linkage command should contain either "libtcl8.4.a" or "-ltcl8.4", but not simply "tcl8.4", generated command is wrong.
I know why: cbp2make was looking for any extension (not just valid ".a") to tell which one of ways to instruct linker is the right one.
Look forward to next revision, this bug is already fixed.

Quote from: ripcordjones on April 23, 2011, 12:58:17 AM
I can try some workarounds, but I thought you might want to know about it in case there are other libraries that use a similar naming scheme.

Yes, thank you. I do need real-world examples of projects to be capable to manage different conditions.

Update: (see rev.99) This is a major preliminary update prior to switching to multiple toolchain architecture.

• Rewrote plaform-specific command generation logic to template-based. Platform-specific commands can be generated in a more flexible way now, probably as it should have been done in the first place. You can find default settings in automatically created cbp2make.cfg configuration file.
  
• Rewrote dependency search for C/C++ source/header files. Extracting dependencies is much faster now, and also you can get some additional info like project statistics on unit usage when running cbp2make with "--verbose" option [prepare a big screen or redirect output to a text file].
  
• Switched makefile generation code to rule-based version. Makefiles became nicer and look more clean, project unit dependencies are also converted into makefile rules now.
  
• Changed format of configuration file to more human-readable form. Old configuration files are partially incompatible, but cbp2make will rewrite new sections with defaults, so just check if everything works fine.
  
• Prepared infrastructure for multiple toolchains (to be completed soon). You can find an example of configuration in cbp2make.cfg. This feature it yet incomplete, and hence will not be activated until (probably) next release, so it is just like a technology preview :) . Toolchain management is planned to be CB-like, but more detailed up to individual tools.
  
• And the last but not least, cbp2make finally got a (imo) funny simple logo.
  
  Well... test it, use it, feel free to report any problems or suggestions. Download link: http://sourceforge.net/projects/cbp2make/files/ (http://sourceforge.net/projects/cbp2make/files/)

Update: (see rev.100) bugfix release

• Added global (per-project) pre-build and post-build steps. When global pre/post build steps are in use, makefile rules are rewritten in slightly different way to allow CB-like behavior (whatever is being built, pre/post build commands are executed only once) when make tool is invoked for either a single virtual target or a single real target ("make all", "make debug", "make release"). However, this won't work completely as intended if make tool is invoked for any multiple targets ("make debug release").
  
• Changed makefile rules naming for build targets. A build target output file name (makefile macro), if any, is no longer used as makefile target name to resolve ambiguity between multiple build targets sharing the same output file name.
  

a remark with respect to casing :

I have a cbp project, with the following targets : Debug and Release

However in the created make file, all is talking about 'debug' and 'release'. I would expect the same casing is used :

Eg :

debug: before_debug out_debug after_debug


would become  (and all other likewise occurrences ) :


Debug: before_Debug out_Debug after_Debug


What do you think ?

Quote from: killerbot on May 09, 2011, 09:37:44 PM
I have a cbp project, with the following targets : Debug and Release
I would expect the same casing is used :

Code Select Expand

Debug: before_Debug out_Debug after_DebugWhat do you think ?

Generally speaking, I have nothing serious to oppose this idea.
Current naming scheme for both macro variables and targets was designed with two things in mind:
1) remove characters unwanted in makefile;
2) bring up some style to make makefile look nice and readable;
and 3) [just came up with this now] when everything is in low case, you don't have to switch case when typing "make <something>" ;) [this is merely a joke]

How do you think, would a kind of "--keep-target-case" option be a solution?

sounds ok for me. I personally would have expected this the default behavior.
But then again, I can live with your suggestion ;-)

Quote from: killerbot on May 09, 2011, 11:12:57 PM
sounds ok for me. I personally would have expected this the default behavior.
But then again, I can live with your suggestion ;-)

Considering the default and a non-default behavior, I have another idea. I'm thinking of putting a thing like "<default_options>bla bla bla</default_options>" into cbp2make.cfg and adding "--def-options "bla bla bla"" option to command line configuration. This way if you want options "--wrap-objects --with-deps --keep-target-case" (for example) to be default options, you have to run cbp2make once with "--def-options "--wrap-objects --with-deps --keep-target-case"" option among others. Those additional options are intended to be immediately attached to other options after reading cbp2make.cfg configuration file, but before doing anything else.

this can work too, but a command line option is always nice, so no copying of config files is needed to wherever you need within to over systems.

Let me explain  : why I expected it to be default behavior. If I decide in my cbp project to call, the target "Debug", then that was my choice. Then I would prefer that no-one is changing it to lowercase, even when it creates new stuff derived from my cbp file.
Say my output directory is Debug, then that one is case preserving, but the name is not when it is translated into a makefile target. Seems a bit inconsistent.

But as said, I can live with your other solutions.

Quote from: killerbot on May 10, 2011, 01:03:03 PMLet me explain  : why I expected it to be default behavior. ...

Good point, I agree.

Quote from: killerbot on May 10, 2011, 01:03:03 PMBut as said, I can live with your other solutions.

I would prefer the default solution to fit user needs better, not just that people could live with my other solutions.

How about that: add an option "--target-case" or "--target-style" with valid values "keep", "lower"/"lowercase", "upper"/"uppercase" and the default value "keep"?
Same solution may be applied to macro variables too...

sounds good : target-case

I'm not a user of cbp2make, but I guess less options is better.

Update: (see rev.101)

I implemented both of ideas discussed above, you may try them now.

• Default options can be stored in configuration file. Use "cbp2make --config options --default-options "<your_options>"" command to pass some of frequently used options to configuration, they will be applied every time you run cbp2make with this configuration, so the actual command line can be shortened.
  
• Implemented optional build target name casing. Use "--target-case <case>" option to select one of possible casings "keep", "lower" or "upper", default value is "keep".
  

Update: (see rev.107) an intermediate release

The next [stable] release is not ready yet, but there were few important changes and I thought it would be nice to indicate that the project is alive.

• Fixed small ugly bug which made makefiles for individual projects and workspace projects completely different.
  
• Partially rewrote makefile generation for multiple toolchain architecture. Commands for build tools are generated with CB-compatible command templates. It mostly works fine with a couple of exceptions: 1) option switches for includes and defines "/I" "/D" in Windows won't work - they can be configured, but not taken into account (hardcoded "-I" "-D" are still in use); 2) linker requirements for paths, prefixes and extensions of libraries are also managed by old code;
  
• Updated tool chain and build tools configuration interface.
  
  While some features are yet incomplete, I hope nothing is seriously broken.
  
  

  Quote
  Usage syntax:
  
          Generate makefile:
                  cbp2make -in <project_file> [-cfg <configuration>] [-out <makefile>]
                           [-unix] [-windows] [-mac] [--all-os] [--flat-objects] [--flat-objpath]
                           [--wrap-objects] [--wrap-options] [--target-case keep|lower|upper]
                  cbp2make -list -in <project_file_list> [-cfg <configuration>]
                           [-unix] [-windows] [-mac] [--all-os] [--flat-objects] [--flat-objpath]
                           [--wrap-objects] [--wrap-options] [--with-deps] [--target-case <case>]
  
          Manage toolchains:
                  cbp2make --config toolchain --add [-unix|-windows|-mac] -chain <toolchain>
                  cbp2make --config toolchain --remove [-unix|-windows|-mac] -chain <toolchain>
  
          Manage build tools:
                  cbp2make --config tool --add [-unix|-windows|-mac] -chain <toolchain>
                           -tool <tool> -type <type> <tool options>
                  cbp2make --config tool --remove [-unix|-windows|-mac] -chain <toolchain>
                           -tool <tool>
  
          Tool types:      pp=preprocessor as=assembler cc=compiler rc=resource compiler
                           sl=static linker dl=dynamic linker el=executable linker
                           nl=native linker
          Tool options (common):
                           -desc <description> -program <executable> -command <command_template>
                           -mkv <make_variable> -srcext <source_extensions> -outext <output_extension>
                           -quotepath <yes|no> -fullpath <yes|no> -unixpath <yes|no>
          Tool options (compiler):
                           -incsw <include_switch> -defsw <define_sqitch> -deps <yes|no>
          Tool options (linker):
                           -ldsw <library_dir_switch> -llsw <link_library_switch> -lpfx <library_prefix>
                           -lext <library_extension> -objext <object_extension> -lflat <yes|no>
  
          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>]
                           [-cp <copy_file_command>] [-mv <move_file_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>]
  
          Manage options:
                  cbp2make --config options --default-options "<options>"
                  cbp2make --config show
  
          Common options:
                  cbp2make --local        // use configuration from current directory
                  cbp2make --global       // use configuration from home directory
                  cbp2make --verbose      // show project information
                  cbp2make --quiet        // hide all messages
                  cbp2make --help         // display this message
                  cbp2make --version      // display version information
  

Tried out rev.107 on a relatively simple project. Works well - thanks for very useful tool.

One small gotcha, if I use a command like `pkg-config --libs someLib` for linking I have to put it (in Codeblocks) under Linker settings; Other linker options.  Then in the generated Makefile it appears under the parameter LDFLAGS (i.e. LDFLAGS = `pkg-config --libs someLib`) which results in a call to g++ along the lines of:

g++  `pkg-config --libs someLib`   somethingA.o   somethingB.o   -o  sometthingExec

This fails due to the linker not finding the pkg-config libraries associated with someLib.

If I manually change the Makefile such that the linking pkg-config command appears instead under LIB (i.e. LIB = `pkg-config --libs someLib`).  Then the resulting g++ linking call is:

g++   somethingA.o   somethingB.o  `pkg-config --libs someLib`  -o  sometthingExec

which works fine.

Not sure if this is something that could easily be fixed?  You could look out for special cases starting with `pkg-config --libs?

Thanks again for a useful tool.

Quote from: pacrook on July 15, 2011, 09:45:34 PMNot sure if this is something that could easily be fixed?  You could look out for special cases starting with `pkg-config --libs?

Where do you put this line in CodeBlocks project configuration? Maybe it should be on linker tab in list of libraries, then it will automatically go to LIB macro. As an alternative solution you can modify the command template for linker and change order of arguments.

Update: (see rev.109) a bugfix release

• Fixed wrong makefile placement when working with a .workspace file, rewrote workspace makefile generation to rule-based approach.
  
• Fixed C/C++ dependency search (files in project directory, i.e. in current working directory, were not included).
  
• Fixed wrong path processing involving empty paths (some paths might end up with "dir/" or "/dir" or "/" instead of "dir" or en empty string)
  
• Implemented translation of project dependencies within a workspace into workspace makefile.
  
• Changed platform configuration, added parameter for "make" tool filename.
  
  If there's something wrong in a fresh makefile, check cbp2make configuration (global "~/.cbp2make/cbp2make.cfg" or local "cbp2make.cfg" in current directory) - wrong (old) default parameters may be stored there. You can simply erase the configuration file to rewrite it with updated default values.

Update: (see rev.110) back from another bug hunt

• Fixed target names in virtual target dependencies. Recently virtual targets were somehow broken and a garbage might appear in a makefile instead of targets' names.
  
• Fixed verbosity setting leading to missing project info output. Dependency information for source files was collected and passed to makefile rules, but it disappeared from regular output in verbose mode.
  
• Modified rules for stored configuration. Previously, cbp2make silently copied its default settings to a configuration file without any questions or notifications to allow further modification of those settings. As the code changes from one revision to another, an old configuration might become incompatible with a new code and result in buggy behavior without a real bug, which lead to confusion. Now cbp2make will not save default settings to a configuration file unless the user explicitly specifies "--config <option>" option to modify some settings. Also, cbp2make will indicate which configuration file it uses (none for initial/default mode).
  

Update: (see rev.112)

• Fixed issue with missing toolchain index for linkers in multi-toolchain projects: all "$(LD#)" were falsely written as "$(LD)" even if a project had more than one toolchain with LD0, LD1, etc. macros defined.
  
  

Update: (see rev.118)

• Fixed [wrong] unit index building procedure that ignored project constraints and attached all units to all of project targets.
  
• Updated documentation for stabilized code. However, it is yet far from being complete.
  
  

Update: (see rev.120)

• Implemented build target selection using option "-targets <target1[,target2[, ...]]>". This option allows to generate individual makefiles for different build targets:
  

  Quotecbp2make -in project.cbp -targets "Debug,Profile" -out Makefile.Debug
  cbp2make -in project.cbp -targets "Release" -out Makefile.Release

  Quotes around parameter of the -targets option may be omitted if target names do not contain spaces.
  
  
• Added options "--keep-objdir" and "--keep-outdir" to save directories for object files and output binary during cleaning step. By default they are forcefully removed by commands of "clean_*" target.

There's something fishy going on with global variables.

I've got these in the global configuration:

    <globalvariables>
        <variableset name="default">
            <variable name="qt4" description="">
                <builtin base="/home/oskari/qt-4.7.4/" include="" lib="" obj="" cflags="" lflags="" />
                <user />
            </variable>
            <variable name="trak" description="">
                <builtin base="/home/oskari/TCF" include="" lib="" obj="" cflags="" lflags="" />
                <user />
            </variable>
        </variableset>
    </globalvariables>


And below is the stuff generated in the top of the makefile:

qt4 = /home/oskari/qt-4.7.4/
qt4_include = /home/oskari/qt-4.7.4//include
qt4_lib = /home/oskari/qt-4.7.4//lib
qt4_obj =
qt4_cflags =
qt4_lflags =
trak = /home/oskari/TCF
trak_include = /home/oskari/TCF/include
trak_lib = /home/oskari/TCF/lib
trak_obj =
trak_cflags =
trak_lflags =

All the variables are in small letters in my original .cbp file, but still theres some places where the variables are either not replaced or they are in all caps:


INC =  -I$(TRAK)/ClientFramework/include -I$(TRAK)/ClientFramework/lib/libstrophe -I$(TRAK)/ClientFramework/lib/qxmpp/src -I$(QT4_INCLUDE) -I$(QT4_INCLUDE)/QtCore -I$(QT4_INCLUDE)/QtNetwork -I$(QT4_INCLUDE)/QtXml
LIBDIR =  -L$(TRAK)/build/lib/$(TARGET_NAME)/ -L$(TRAK)/ClientFramework/lib/qxmpp/lib -L$(QT4_LIB)
OUT_DEBUG = $(#trak)/build/bin/$(TARGET_NAME)/TCF.so

...

before_Debug:
        test -d $(#trak)/build/bin/$(TARGET_NAME) || mkdir -p $(#trak)/build/bin/$(TARGET_NAME)

...


This causes problems at least for me, because make seems to be case-sensitive when it comes to variables. Also, would it be possible to define the $(PROJECT_NAME) and $(TARGET_NAME)? For example, I have the following in my .cbp:

<Target title="Debug">
    <Option output="$(#trak)\build\bin\$(TARGET_NAME)\TCF" prefix_auto="1" extension_auto="1" />
    <Option object_output="$(#trak)\build\obj\$(TARGET_NAME)\$(PROJECT_NAME)\" />
    ...

Quote<builtin base="/home/oskari/qt-4.7.4/"

Should above end with a "/"?

Tim S

Quote from: oswjk on November 24, 2011, 10:46:12 AM
There's something fishy going on with global variables.
I've got these in the global configuration:

Yeah, I see. There's something wrong with target and macro variable casing.
While one of identifier casings (upper,lower,as-is) follows the configuration, another one does not.

Thanks for your effort. This is definitely a bug and I will fix it ASAP.

p.s. Please, send your project file (.cbp) to mirai.computing@gmail.com so I could test against it. I don't have any active projects with global variables in setup.

I think I solved this issue with global compiler variables, but I still need a .cbp file to test against it.

Quote from: oswjk on November 24, 2011, 10:46:12 AM
Also, would it be possible to define the $(PROJECT_NAME) and $(TARGET_NAME)? For example, I have the following in my .cbp:

Code Select Expand

<Target title="Debug">
    <Option output="$(#trak)\build\bin\$(TARGET_NAME)\TCF" prefix_auto="1" extension_auto="1" />
    <Option object_output="$(#trak)\build\obj\$(TARGET_NAME)\$(PROJECT_NAME)\" />
    ...

Yes and no :) A $(PROJECT_NAME) macro is simple, I can add this right now.
But $(TARGET_NAME) is a completely different thing - it should be different for every target in a makefile.
Hence, processing of $(TARGET_NAME) should be either
1) a dirty hack inside cbp2make which I would like to avoid;
2) a bunch of macros like "TARGET_NAME_DEBUG = Debug" which is easy to add and is not a hack but looks less nicely;
3) a generic feature to support some internal macros - but it is not clear to me what macros should be there.

Quote from: mirai on November 24, 2011, 05:37:38 PM

Quote from: oswjk on November 24, 2011, 10:46:12 AM
There's something fishy going on with global variables.
I've got these in the global configuration:

Yeah, I see. There's something wrong with target and macro variable casing.
While one of identifier casings (upper,lower,as-is) follows the configuration, another one does not.

Thanks for your effort. This is definitely a bug and I will fix it ASAP.

p.s. Please, send your project file (.cbp) to mirai.computing@gmail.com so I could test against it. I don't have any active projects with global variables in setup.

I'll send you one tomorrow when I'm back at work.

Update: (see rev.125)

• Implemented toolchain selection without explicit duplicates.
  
• Added an option to control case of macro variables. Use "--macros-case [lower|upper|keep]" option to select casing for macros. Defaults are also changed, macros now are all in upper case while targets are all in lower case by default.
  
• Fixed case mismatch issues for global compiler variables.
  
• Fixed platform selection. It seems that for many revisions along selecting a single platform/OS would bring all incompatible targets to makefile, however, selecting multiple platforms never lead this bug.
  

Update: (see rev.127) a quick bugfix release

• Fixed possible crash due to undefined toolchain introduced somewhere between rev.120-125.
  
• Revisited global compiler variable evaluation code. Some strings previously have escaped macro substitution, now that is corrected.

Update: (see rev.130)

• Implemented handling of spaces and special characters in paths.
  
  Try this revision if you previously experienced any problems with 'make' complaining about wrong paths.

From my personal experience, this is a useful tool which does exactly what it is supposed to do in the vast majority of cases.  I would suggest it be considered for inclusion in Code::Blocks' svn (in trunk/src/tools (http://svn.berlios.de/wsvn/codeblocks/trunk/src/tools/)).  What do other people think?

Update: (see rev.133)

• Fixed reading of virtual targets from project file. All virtual targets but the first one were missing due to a bug.
  
• Implemented build target selection for virtual targets. Previously, target selection with option "-targets" worked only for real build targets, but now it works for virtual targets as well.
  

Hello!

This tool is exactly what I was searching for. I am in Windows and I am trying to create a makefile from my .cbp project. The problem is that when I try to do that cbp2make crushes immediately.

I am typing in:
cbp2make -in foo.cbp
The output I get is:
Starting cbp2make rev.133...
Using default configuration.
Loading file 'foo.cbp': [DONE]
Generating makefile(s): foo.cbp.mak:


After that the crush happens.

Any idea why this might be happening or methods to correct it?
My project is actually cross-platform thanks to CB so, I am gonna go to my Linux pc and try to run cbp2make in the same project from there and see the results.

I tested it in Linux too and the same thing happened. So it must be something inside the .cbp file
I have different build targets in the .cbp project. Should not affect the generation process though right?


Further Edit:
Since I had the source I thought I should try to debug it and maybe see if the seg fault is something easy to fix. After lots of trial and error and updates on this post I found what was happening.

The problem is in line 1098 of src\cbproject.cpp


    CBuildUnit *unit = m_UnitIndex[i];
    CCompiler *compiler = tc->FindCompiler(unit->Extension());
    /*
    std::cout<<"target "<<target->Name().GetString()
             <<" unit "<<unit->m_FileName.GetString()
             <<" compilable "<<unit->IsCompilable()
             <<" compile "<<unit->m_DoCompile
             <<" link "<<unit->m_DoLink<<std::endl;
    */
    if( compiler !=0) /// Extra check added by Lefteris, so as not to delete the original check
    {
   //if (((0!=compiler)||(!unit->CompilerVariable().IsEmpty()))&&(unit->DoCompile()))//original check
     CString compiler_var = compiler->MakeVariable(); /// SEG FAULT HERE
     if (unit->CompilerVariable().IsEmpty())
     {
      compiler_var = compiler->MakeVariable();
     }


The original if check allows  the program to get in the compilable unit scope even if the CCompiler* pointers is 0. So for all the header files of my project it was getting in there and was causing a seg fault.

I made a temporary fix of this if check by just checking only for compiler pointer being 0.

Further Edit 2

I discovered another bug. In windows during the linking stage the loading flags were output to the
beginning right after the $(LD). That resulted in undefined referenced during making.

out_win32_debug_test: $(OBJ_WIN32_DEBUG_TEST) $(DEP_WIN32_DEBUG_TEST)
$(LD)  $(LDFLAGS_WIN32_DEBUG_TEST) $(LIBDIR_WIN32_DEBUG_TEST) $(OBJ_WIN32_DEBUG_TEST) $(LIB_WIN32_DEBUG_TEST) -o $(OUT_WIN32_DEBUG_TEST)

I am not sure if this is an issue of cbp2make or if it is supposed to be okay to put the Loader Flags wherever you want, but moving them to the very end like that solved my problem.

out_win32_debug_test: $(OBJ_WIN32_DEBUG_TEST) $(DEP_WIN32_DEBUG_TEST)
$(LD) $(LIBDIR_WIN32_DEBUG_TEST) $(OBJ_WIN32_DEBUG_TEST) $(LIB_WIN32_DEBUG_TEST) -o $(OUT_WIN32_DEBUG_TEST) $(LDFLAGS_WIN32_DEBUG_TEST)


Thanks for testing the tool. I will recheck this issue and apply a permanent fix. You can help me by sending a sample project file that caused crash in rev.133 to my email.

Considering options order, you can rewrite command line for Windows platform in cbp2make configuration. Just run "cbp2make --config options --local" in project directory and then change defaults in cbp2make.cfg to your corrected version by moving around macros in linkage command. I'm not sure if I have to change defaults, C::B uses just the same order of linker options.

Update: your issue is now registered here: https://sourceforge.net/apps/mantisbt/cbp2make/view_all_bug_page.php

If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

Quote from: Freem on May 07, 2012, 02:53:38 PM
If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

That site is simply a wiki provided by sourceforge, I didn't do anything weird to it and didn't even touched it for a long time. Maybe something is got broken on sf.net side... Now have to contact sf.net administration  :(.

Quote from: mirai on May 07, 2012, 10:30:22 PM

Quote from: Freem on May 07, 2012, 02:53:38 PM
If you are the maintainer of the sourceforge's website of cbp2make, you have a problem with your website, you redirect on a php page... and here (opera browser) I can only save it.

That site is simply a wiki provided by sourceforge, I didn't do anything weird to it and didn't even touched it for a long time. Maybe something is got broken on sf.net side... Now have to contact sf.net administration  :(.

The Wiki for another site on sourceforge stopped working today.

Note: This site that says what is down is also down
https://sourceforge.net/apps/wordpress/sourceforge/ (https://sourceforge.net/apps/wordpress/sourceforge/)

Edit: I get this message today.

Quote
With the exception of Trac, the Hosted Apps platform on the SourceForge site are offline.

-- SourceForge.net team.
Site Status:

loading latest tweet...

Tim S.

Update: (see rev.135)

• Fixed possible crash when compiler variable is overridden for a unit and that unit has an unrecognized extension.
  
• Quick fix for handling relative paths outside project tree. Elements ".." of relative paths for object files are replaced with "__" strings, so all object files which sources are outside of project tree will be along all other object files in a specified subdirectory of the project.
  

Update: (see rev.137)

• For Windows GUI builds "-mwindows" option is now supplied to the GCC linker, for other manually added compilers (toolchains), an "option_wingui" is available in the cbp2make configuration.
  
• Fixed output path for Windows resource compiler (a path separator was missing).
  
• Removed false messages about missing compiler for non-compilable units.
  
• Fixed command line syntax for linking with libraries, some project options were mistreated and "-l" switch was misplaced.
  

I made an account to say thank you!  I like to use MinGW32 + msys, and I'm trying to build SFML without codeblocks.  It looks like it will work once I install Qt.

One request, if HOME env is defined, I'd rather use it than Windows user path.  It seems that --config didn't create the .cbp2make directory in C:/Users/Account automatically from MSYS.  --local works OK.  All the different toolchain settings are overwhelming, but I didn't need them so no problem.

Quote from: axus on September 08, 2012, 08:30:30 PM
One request, if HOME env is defined, I'd rather use it than Windows user path.  It seems that --config didn't create the .cbp2make directory in C:/Users/Account automatically from MSYS.  --local works OK.  All the different toolchain settings are overwhelming, but I didn't need them so no problem.

I just followed the Qt implementation in this regard, but overriding this default behavior is not a problem I think.
Good piece of plan for the next release. :)

I generated a makefile using this tool and it looks great, thanks! However when I "make"  the project, it does not find the wxWidgets libraries even though the `wx-config --libs` directive is there. It does find the wxWidgets include files using the `wx-config --cflags` directive. If I just cut and paste the output from wx-config --libs command run manually into the generated makefile at the line LIB =, everything works fine. It's like the `wx-config --libs` command does not get run at the linker step, even though it's there. The use of wx-config is a must for wxWidgets if one is planning on distributing an open source program.

Any suggestions?

Thanks,
Ken

Quote from: ktmpal on December 13, 2012, 04:08:21 PM
The use of wx-config is a must for wxWidgets if one is planning on distributing an open source program.

I'd rather say that learning autotools is a must when one wants to distribute open source programs.

On the problem: have you tried to for make to print debug output and see what commands get executed?

I agree with your autotools comment. However, one really needs a makefile to use as a makefile.in template. And yes, I have used the -n option. The line in question is:

g++ -s `wx-config --libs` -L/usr/local/lib obj/Release/src/PicKit2Main.o obj/Release/src/PicKit2App.o obj/Release/src/HexTextCtrl.o obj/Release/src/HexRecord.o obj/Release/src/HexEditDlg.o obj/Release/src/HexEditCtrl.o obj/Release/src/DeviceFile.o obj/Release/src/DeviceDlg.o  -o bin/Release/pk2cmdUI

The wxWidgets team solved this.

If you move the `wx-config --libs` to the end, just before the -o, it works.

The author of cbp2make should make note of this.

Thanks,
Ken

AFAIK, a wxWidgets project is configured using a global compiler variable WX in terms of Code::Blocks IDE.
Dereferencing this variable with #WX is purely mechanical, and placing the macro in a command line is up to the author of a project.
cbp2make does not enforce the placement of the macro in any exact location, the tool just makes string substitutions.

Please correct me if I'm wrong at this point.

Update: (see rev.138) a small bugfix release

• Fixed possible out-of-order execution of makefile rules when -jN option is used, which might happen due to missing dependencies between before-build,build,after-build rules.
  
• Fixed possible 'could not find getcwd' build error in recent distributions due to missing #include.
  
• Corrected default command templates for GCC dynamic library and executable linker.
  
• Added support for multiple platform-specific library extensions. This list of file extensions is used to check whether a supplied file name is a full library name ("libabc.a") or just a base name ("abc") which requires "-l" linker option. See cbp2make.cfg configuration file, platforms section.
  

Can anyone explain tom how to use this tool?

Quote from: freq on June 01, 2013, 10:46:49 AM
Can anyone explain tom how to use this tool?

Read this site http://sourceforge.net/apps/mediawiki/cbp2make/index.php?title=Main_Page (http://sourceforge.net/apps/mediawiki/cbp2make/index.php?title=Main_Page)

Tim S.

great work! thank you very much!

Update: (see rev.147) an intermediate release

• Fixed setting of automatic file prefix for targets ('lib' for static libraries, etc).
  
• Partially reworked support for multiple toolchains. Different toolchains with incompatible command line switches can be used now in one project.
  
• Declared MSVC and Borland toolchains, other toolchains known to C::B will be there in further releases.
  
• Some other minor bugfixes and changes I don't remember  ;)
  
  The progress on cbp2make became quite slow recently.
  Despite many planned things are not there yet, I'd like to share some of already implemented improvements.

This looks like a handy tool!

Is there a way to specify Code::Blocks's conf file?  I scanned this topic and looked at the config doc for cbp2make and did not see anything obvious.

I use several different conf file depending on the toolchain and whether the project build environment is portable or not.

Update: seems as if cbp2make does not reference a conf file.  I am getting error:

Generating makefile(s): test_UART.cbp.mak: Warning: toolchain 'armelfgcc' for target 'Debug' is not defined.
Warning: toolchain 'armelfgcc' for target 'Release' is not defined.
Warning: toolchain 'armelfgcc' for target 'Debug' is not defined.
Warning: toolchain 'armelfgcc' for target 'Release' is not defined.

Does this mean that global settings are not included?

Update 2:
I created a new armelfgcc toolchain entry in the CFG file.  cbp2make seems to be happy with that.
Now to move any global settings to the project settings.

Update 3:
Work pretty good!  But, it is ignoring assembly files (.s & .S).  I'll manually add those and report on progress.

Last Update:
I added the assembly files and the output file was generated successfully, when the (modified) make file was ran!
Two additional things I had to fix:
1) When clean is specified, the order that the directory deletions was done was incorrect.  It attempted to remove a parent directory before a sub directory was removed.  Also, it does not remove any nested parent directories that did not contain files. As an example: I had a source file file in level5
.\level1\level2\level3\level4\level5\file.o
it attempted to remove .\level1 before removing .\level1\level2\level3\level4\level5
Also, it did not attempt to remove .\level1\level2\level3\level4, .\level1\level2\level3 or .\level1\level2 directories I presume because they did not contain any object files.

2) Is there any way I can resolve the Code::Blocks predefined symbols %TARGET_OUTPUT_DIR% and %TARGET_OUTPUT_BASENAME% without defining exact directory and file name?

Ha, I lied, one more update:
I tried to add a single variable, but it is always added as a set.  It works OK, just adds a lot of unnecessary verbiage to the make file.

Thank you very much for putting the effort into creating this application!
Vance

Hi, veneff. Sorry for terribly long reply. Haven't check this forum thread for few months.

Currently cbp2make knows only few toolchains by default. It is planned to add all toolchains known to C::B, but only few defaults were hard-coded up until now. Update2 steps are entirely correct, this is the intended way to add toolchains unknown by default.

In order to process assembly file "*.s"/"*.S" you need a defined compiler tool in a toolchain that has these extensions declared as input file extensions (put <option source_extensions="s S"/> line in config xml of the assembler section).

Directory cleanup order may be incorrect, it is just extracted from the list of output file paths as I remember.

Built-in variables are not supported yet.
Adding support for them had been planned as a major update after rev.147,
but I had to put the project on hold due to horrible lack of spare time.

cbp2make does not use global C::B compiler's settings.
There are -L"lib_path" and -lm linker's switches in C::B Settings->Compiler->Linker Settings, but there are not the switches in output makefile.

Dvorkin

Yes, that's true. cbp2make doesn't use anything that's outside of .cbp or .workspace file (and it shouldn't by design) since the major reason for developing cbp2make was to being able to build C::B projects on systems where C::B is not available. The suggested solution to pass information which is external to a project is to use local or global configuration of cbp2make where it stores information about toolchains and system commands. However, current version of cbp2make does not implement this kind of toolchain-wise settings.

As a quick workaround to this I would suggest to move these settings to global project settings.

Please be aware that there is an inconsistency in how cbp2make is handling generation of a list of linking libraries for the linker as compared to CodeBlocks.

For more information please see my reply to the Stack Overflow question: http://stackoverflow.com/questions/25670849/cbp2make-linking-libraries-with-a-on-windows/27672601#27672601

It is my opinion that cbp2make behaviour should be corrected to mach CB (required settings and variables holding file extensions are already present).

Currently cbp2make doesn't make any difference between static and dynamic libraries when it is about to generate a line for the linker.
Well, my assumption about how this should work was wrong and this is why it is designed that way.

Input conditions are: ( ) a library has a known extension ( ) static ( ) dynamic ( ) any other extension ( ) no extension ( ) a library has a known prefix;
Possible actions: ( ) remove prefix ( ) remove extension ( ) add library linking switch;

the.sniffer, could you write down the required logic in these terms as you see it? (like you did on stackoverflow.com)

I'd suggest you have a look at "src/sdk/compilercommandgenerator.cpp" in CodeBlocks source code for the most accurate response. There are a lot of options that come into play, and I'd hate to make a mistake.

this is really a great tool. in the previous version i got nothing wrong, but this latest one i have this problem:
i have static library project, for example the name is "abc". in the project properties it's already set that the output filename is "bin/Debug/libabc.a". but when i generate the makefile using cbp2make and build it, the output file is generated with the name "liblibabc.a" instead of "libabc.a". it results the linking process failed because the linker cannot find the library abc. why does it happen? or is there any workaround to fix this? thanks

EDIT:
apologies. as it turns out, i just realized that the version of codeblocks i used was 10.05 which i got from the wheezy distribution of debian. in this version the output file explicitly set as "libabc" unlike on the version 13.12 that just set as "abc".

I have a workspace with 2 projects, one uses the MINGW GCC to build it and the other uses MINGW64 to build.
Actually these projects deliver a DLL, one for 32 bit and one for 64 bit.
cpb2make does not generate a makefile for the 64 bit project, it trows the error message:
Warning: toolchain 'gnu_gcc_compiler_w64' for target 'DLL' is not defined.

In code::blocks I defined the 64 compiler using the menu settings->compiler (as described in this clear expanation (thanks!!) http://yzhong.co/?p=622)

I can see one can add a configuration but how to do it? How does a configuration file look like? I looked at the output of cbp2make --config show but there is no folder location mentioned. I suppose I have to tell it through the configuration file where the compiler/linker is located? (Since I have two versions of MINGW on my computer)

fruitCode
Compiler settings from C::B are not transferred to cbp2make.cfg automatically, you have to specify options separately from C::B.

Run cbp2make --config --local , this will create cbp2make.cfg file in the current directory. Then you can edit this XML file either with a regular text editor or by running cbp2make with certain options. I think using a text editor would be easier.

Find a section like this

        <toolchain platform="Windows" alias="gcc">
            <tool type="compiler" alias="gnu_c_compiler">
                <option description="GNU C Compiler" />
                <option program="gcc.exe" />
                <option make_variable="CC" />
                <option command_template="$compiler $options $includes -c $file -o $object" />
                <option source_extensions="c cc" />
                <option target_extension="o" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option include_dir_switch="-I" />
                <option define_switch="-D" />
            </tool>
            <tool type="compiler" alias="gnu_cpp_compiler">
                <option description="GNU C++ Compiler" />
                <option program="g++.exe" />
                <option make_variable="CXX" />
                <option command_template="$compiler $options $includes -c $file -o $object" />
                <option source_extensions="cpp cxx" />
                <option target_extension="o" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option include_dir_switch="-I" />
                <option define_switch="-D" />
            </tool>
            <tool type="static_library_linker" alias="gnu_static_linker">
                <option description="GNU Static Library Linker" />
                <option program="ar.exe" />
                <option make_variable="AR" />
                <option command_template="$lib_linker rcs $static_output $link_objects" />
                <option source_extensions="o obj" />
                <option target_extension="a" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option library_dir_switch="-L" />
                <option link_library_switch="-l" />
                <option object_extension="o" />
                <option library_prefix="lib" />
                <option library_extension="a" />
                <option need_library_prefix="0" />
                <option need_library_extension="0" />
                <option need_flat_objects="0" />
            </tool>
            <tool type="dynamic_library_linker" alias="gnu_dynamic_linker">
                <option description="GNU Dynamic Library Linker" />
                <option program="g++.exe" />
                <option make_variable="LD" />
                <option command_template="$linker -shared $link_options $libdirs $link_objects $libs -o $exe_output" />
                <option source_extensions="o obj" />
                <option target_extension="dll" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option library_dir_switch="-L" />
                <option link_library_switch="-l" />
                <option object_extension="o" />
                <option library_prefix="lib" />
                <option library_extension="dll" />
                <option need_library_prefix="0" />
                <option need_library_extension="0" />
                <option need_flat_objects="0" />
            </tool>
            <tool type="executable_binary_linker" alias="gnu_executable_linker">
                <option description="GNU Executable Binary Linker" />
                <option program="g++.exe" />
                <option make_variable="LD" />
                <option command_template="$linker $link_options $libdirs $link_objects $libs -o $exe_output" />
                <option source_extensions="o obj" />
                <option target_extension="exe" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option library_dir_switch="-L" />
                <option link_library_switch="-l" />
                <option object_extension="o" />
                <option library_prefix="" />
                <option library_extension="" />
                <option need_library_prefix="0" />
                <option need_library_extension="0" />
                <option need_flat_objects="0" />
                <option option_wingui="-mwindows" />
            </tool>
            <tool type="resource_compiler" alias="gnu_windres_compiler">
                <option description="GNU Windows Resource Compiler" />
                <option program="windres.exe" />
                <option make_variable="WINDRES" />
                <option command_template="$rescomp -i $file -J rc -o $resource_output -O coff $includes" />
                <option source_extensions="rc res coff" />
                <option target_extension="o" />
                <option need_quoted_path="0" />
                <option need_full_path="0" />
                <option need_unix_path="0" />
                <option include_dir_switch="-I" />
                <option define_switch="-D" />
            </tool>
        </toolchain>


Copy this text next to itself and replace the value of "alias" option with exactly the same text as in .cbp file in line "<Option compiler = "gcc">", then modify options of build tools to match C::B settings.

Hi!

There's an old problem with sourceforge.net which lately became intolerable. After sourceforge.net had canceled hosting MediaWiki by default, the cbp2make wiki went dead. While I was doing other projects I couldn't pay attention to this issue and for a long time it stayed unnoticed. All I have now is something that looks like an SQL dump of MySQL database for MediaWiki. I tried to reinstall MediaWiki manually and recover the contents from this backup, but it doesn't seem to work all way through. The database is up and running but wiki is replaced with some new 'wiki' service and I can't make it access my installation of MediaWiki instead of this new built-in service.

Can anyone help me to retrieve HTML or plain text contents of wiki from SQL dump (in attachment) ?

See attached.

Quote from: Alpha on March 14, 2015, 06:48:00 PM
See attached.

Great! Thanks a lot!

What's the current state of this project?

Any update on variable support? I know that C::B variables are a mess in themselves.. (that is, no documentation, no preview function etc... you'll have to guess and Google how to use them^^ The IDE doesn't help you at all. Besides the "tools" that use their own variables... though often redundant as there exist C::B equivalents..)

- Would be nice if I could just use those post-build steps:
objcopy --only-keep-debug $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).dbg
objcopy --strip-debug --strip-unneeded --add-gnu-debuglink=$(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).dbg $(TARGET_OUTPUT_FILE)

---

- The current version fails to create virtual targets... basically it only ever creates the first virtual target. (which is one reasons I can't use it)

---

- Targets cannot share object files... at least not without warnings such as:
Makefile:457: warning: overriding recipe for target '.obj\\common\\clock.o'
Makefile:383: warning: ignoring old recipe for target '.obj\\common\\clock.o'
383: $(OBJDIR_CALENDAR)\\common\\clock.o: common\\clock.c
$(CC0) $(CFLAGS_CALENDAR) $(INC_CALENDAR) -c common\\clock.c -o $(OBJDIR_CALENDAR)\\common\\clock.o
457: $(OBJDIR_APP)\\common\\clock.o: common\\clock.c
$(CC0) $(CFLAGS_APP) $(INC_APP) -c common\\clock.c -o $(OBJDIR_APP)\\common\\clock.o

---

- I would also love if virtual targets wouldn't be prefixed "virtual_". I guess no one wants to "make virtual_debug" when it could be "make debug" or "make release" or even "make all" (that is, allow a virtual "all" target to overwrite default "all")

---

- cbp2make doesn't properly append target options to project global ones.. It creates code like this: "$(LIB0)-lComctl32", notice the missing space.

---

- clean fails if a directory or file was already "cleaned" and no longer exists... it doesn't properly handle shared object as well, because it tries to remove the object directory which might still contain objects..


And about Sourceforge... why not just move on to GitHub or GitLab ;)

---

addition 06/11/2015:
just noticed that
- "use target options only" doesn't always work.. seems to work for compiler options and some linker options, but not for link libraries

---

- "target_extension"/"library_extension" config option is totally ignored. At least for "executable_binary_linker" and "dynamic_library_linker" because cbp2make only ever uses AutoFileExtension() which doesn't use "target_extension" at all and returns the target OS' default

---

addition 06/16/2015:
- "option_wingui" should work for any platform. Currently it's wrapped around an if ((pl->OS()==CPlatform::OS_Windows) && (target->Type()==CBuildTarget::ttExecutable))But the platform check is redundant as "option_wingui" is empty on any non-Windows platform... and if it's not, there's a high chance that it is required. So don't limit options by platform, let options "limit" themselves. (this basically prevents proper cross-platform builds / makefile generation)

---

- if make is called with -j 4 to use parallel-builds, post-build steps might fail because they don't depend on the base build step (out_*)
  though, it seems like cbp2make knew about this issue when it created "out_*" steps as they depend properly on "before_*" (pre-build)

The project is in "passive development" since I had to switch to other tasks.
Support for built-in variables is partially implemented, there's not so much work left.
Plain built-in variable substitution will work, but conditional evaluation won't be implemented at this stage.
I keep looking for feedback and collecting it, useful 3rd party additions will be integrated or reimplemented in the original code.

I see that many people use cbp2make and I'm perfectly aware of how unfinished it is.
From time to time I try to switch "passive development" into active one, but my current work keeps me very busy.
Nevertheless, I have a strong intention to make cbp2make functionally complete tool.
I'm using it in my work too! It was developed from this need in the first place. :)

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- Would be nice if I could just use those post-build steps:

Yes, good example, I also need macros like these for microcontroller firmware projects.
Another major drawback is that cbp2make is not importing compiler configuration from C::B in any way.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- The current version fails to create virtual targets... basically it only ever creates the first virtual target. (which is one reasons I can't use it)

Oh, that's interesting. Virtual targets are supported but I can't see them in my makefiles.
Probably they are filtered out my mistake during platform compatibility checking. Should be easy to fix.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- Targets cannot share object files... at least not without warnings such as:

They shouldn't share them. I personally consider this a poorly configured project.
To enable shared object files between targets one should at first verify that the build options for these files are effectively equal between targets.
Otherwise you're messing up your project by mixing in possibly incompatible object files.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- I would also love if virtual targets wouldn't be prefixed "virtual_". I guess no one wants to "make virtual_debug" when it could be "make debug" or "make release" or even "make all" (that is, allow a virtual "all" target to overwrite default "all")

OK, I agree to make this configurable. This was initially done to resolve name conflicts between default and virtual targets.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- cbp2make doesn't properly append target options to project global ones.. It creates code like this: "$(LIB0)-lComctl32", notice the missing space.

There were such issues before, but they should be already fixed by now. Does this bug still occur?

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- clean fails if a directory or file was already "cleaned" and no longer exists... it doesn't properly handle shared object as well, because it tries to remove the object directory which might still contain objects..

This follows exactly from the same rule that object files must not be shared between targets.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
And about Sourceforge... why not just move on to GitHub or GitLab ;)

Actually I'm using Git internally and some other Git-related gear for managing projects.
However, the original repository also contains things I can't share. Sorry about that.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- "use target options only" doesn't always work.. seems to work for compiler options and some linker options, but not for link libraries

AFAIR, that's probably because libraries are processed in a different way.
Can't tell for sure, haven't seen the code for a while.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- "target_extension"/"library_extension" config option is totally ignored. At least for "executable_binary_linker" and "dynamic_library_linker" because cbp2make only ever uses AutoFileExtension() which doesn't use "target_extension" at all and returns the target OS' default

I don't remember now why it is this way. Maybe just an incomplete implementation. Need to take a look at the code.

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- "option_wingui" should work for any platform. Currently it's wrapped around an

Code (c) Select Expand

if ((pl->OS()==CPlatform::OS_Windows) && (target->Type()==CBuildTarget::ttExecutable))But the platform check is redundant as "option_wingui" is empty on any non-Windows platform... and if it's not, there's a high chance that it is required. So don't limit options by platform, let options "limit" themselves. (this basically prevents proper cross-platform builds / makefile generation)

AFAIR I considered that this kind of cross-platform builds is next to nonexistent.
Do you build Windows applications on Linux/Mac/... with native tools and foreign libraries?

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- if make is called with -j 4 to use parallel-builds, post-build steps might fail because they don't depend on the base build step (out_*)
  though, it seems like cbp2make knew about this issue when it created "out_*" steps as they depend properly on "before_*" (pre-build)

Looks like I've just missed this little thing. Easy to fix.

White-Tiger, can you send me some .cbp files for testing?
Please leave them here in attachment or send to mirai.computing@gmail.com

Quote from: mirai on June 22, 2015, 09:50:31 PM

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- Targets cannot share object files... at least not without warnings such as:

They shouldn't share them. I personally consider this a poorly configured project.
To enable shared object files between targets one should at first verify that the build options for these files are effectively equal between targets.
Otherwise you're messing up your project by mixing in possibly incompatible object files.

actually a reason why targets should be able to share them.
One project usually got the very same compiler options, if you're forced to split it into different projects so that make files are properly generated, it's way more likely to have incompatible compiler flags...
And sharing the very same source files shouldn't be a problem as well... In case you're compiling multiple programs that share some common code. (ok, one could use different object directories...)

Quote from: mirai on June 22, 2015, 09:50:31 PM

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- cbp2make doesn't properly append target options to project global ones.. It creates code like this: "$(LIB0)-lComctl32", notice the missing space.

There were such issues before, but they should be already fixed by now. Does this bug still occur?

I'm always using the latest versions before I report stuff.. besides I'm generally always using (and checking for) the latest version before I use a program.
And your latest release is rev147 which is 2 years old.

Quote from: mirai on June 22, 2015, 09:50:31 PM

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- clean fails if a directory or file was already "cleaned" and no longer exists... it doesn't properly handle shared object as well, because it tries to remove the object directory which might still contain objects..

This follows exactly from the same rule that object files must not be shared between targets.

Untrue, this issue doesn't exist on Linux. *nix generated makefiles use "if"'s before trying to delete files. Windows does not.
This basically means that you can't "make clean" twice, or can't use it on a clean checkout of a repository.. (just to make sure everything is cleaned)
It shouldn't fail though. Trying to delete a file that doesn't exist, still means that the file is successfully deleted / non-existent and the result is the expected clean state

Quote from: mirai on June 22, 2015, 09:50:31 PM

Quote from: White-Tiger on June 09, 2015, 04:37:50 PM
- "option_wingui" should work for any platform. Currently it's wrapped around an

Code (c) Select Expand

if ((pl->OS()==CPlatform::OS_Windows) && (target->Type()==CBuildTarget::ttExecutable))But the platform check is redundant as "option_wingui" is empty on any non-Windows platform... and if it's not, there's a high chance that it is required. So don't limit options by platform, let options "limit" themselves. (this basically prevents proper cross-platform builds / makefile generation)

AFAIR I considered that this kind of cross-platform builds is next to nonexistent.
Do you build Windows applications on Linux/Mac/... with native tools and foreign libraries?

Not sure what you mean exactly...
I'm using MinGW on Linux by installing "binutils-mingw-w64-i686 gcc-mingw-w64-i686 g++-mingw-w64-i686".. Yet MinGW still requires the right switch to generate GUI applications for Windows... otherwise my cross-compiled programs will still show a console when run on Windows.

-- For testing:
You could use the project I'm using: https://github.com/White-Tiger/T-Clock.git
cd ./Source
# Make a copy of the manually fixed "Makefile.unix"
cbp2make --wrap-objects --keep-outdir --local -in T-Clock-gcc.cbp -out Makefile.unix -unix
and compare these... (ignore the -Os option, had to remove that to make it build on Ubuntu)

Hi,
Long time ago I began implementing support for C::B built-in variables, but that work hasn't been finished.
At that time things stuck at macro expansion as there wasn't a clear picture of how to integrate this into existing code.
Reviewing the sources I came up with following questions:

Q1: When should built-in variable expansion take place, at makefile generation time or at actual build time?
With 2nd option there are two ways to do this:
a) cbp2make must be run right before Make every time to update time-dependent variables;
b) cbp2make must respond with built-in variable values via CLI and it is up to Make to do the expansion.

Q2: Who should do built-in variable expansion, cbp2make while generating a makefile or Make while building stuff?
Again, with 2nd option, cbp2make must not expand variables to their real values, but rather convert them to Make-friendly macros.

Q3: When cbp2make is used in an environment without C::B IDE installed, how should it set C::B installation related variables?
Same question goes for ACTIVE_EDITOR_* variables. By default all undefined variables are empty strings.

Hi, I always wanted to have a tool like this, somehow cbp2make almost provided a solution but not quite.

I think you ask essential questions. I think variables should be expanded at build time, make should do it.

I use global variables in C::B extensively, making it possible for me to share C::B project files between computers and even between Windows/Linux OSes. But it does not address the scenario where someone wants to build the code without having C::B installed, someone who "just wants to run a makefile".

Would it be possible to have cbp2make store the C::B global variables in an .env file (or equivalent) and somehow let the makefile expand the values from that file? If so, one could build the code on a computer with no C::B installed by editing the values of the .env file only, not touching the generated makefile.

Disclaimer beforehand: I am one of the users of this tool and I like it, but also had slightly modify it to suit my (very special) needs.

Quote from: mirai on July 25, 2023, 10:35:14 AM
Q1: When should built-in variable expansion take place, at makefile generation time or at actual build time?

I'd say option 1 makes probably most sense. Makefile generation. They could be created as normal variables that are being expanded.

Quote from: mirai on July 25, 2023, 10:35:14 AM
Q2: Who should do built-in variable expansion, cbp2make while generating a makefile or Make while building stuff?

My preference: Again option 1.

Quote from: mirai on July 25, 2023, 10:35:14 AM
Q3: When cbp2make is used in an environment without C::B IDE installed, how should it set C::B installation related variables?
Same question goes for ACTIVE_EDITOR_* variables. By default all undefined variables are empty strings.

That is a tricky one. I'd say the ACTIVE_EDITOR alike variables there is not much you can do but also, whoever needs these variables for builds does that probably temporarily only and so there is no need for a Makefile ever. For the rest: Just rely on the user here: Ask step-by-step for a user input, explaining the situation beforehand, something like: "cbp2make does not know the global variables of a code::blocks installation so these need to be provided manually.".

...just my 2ct...

Hi, this is a nice tool, and someone are using this tool to build C::B by the github action, you can see discussion here:

build bot in the github, I see one nice project (https://forums.next.codeblocks.org/index.php/topic,25856.0.html)

Nice work!

EDIT:

Where can I find the binary file of this tool?

Quote from: ollydbg on August 25, 2024, 02:16:17 AM
Hi, this is a nice tool, and someone are using this tool to build C::B by the github action, you can see discussion here:

build bot in the github, I see one nice project (https://forums.next.codeblocks.org/index.php/topic,25856.0.html)

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

Quote from: stahta01 on August 25, 2024, 04:05:54 AM

Quote from: ollydbg on August 25, 2024, 02:16:17 AM
Hi, this is a nice tool, and someone are using this tool to build C::B by the github action, you can see discussion here:

build bot in the github, I see one nice project (https://forums.next.codeblocks.org/index.php/topic,25856.0.html)

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

Hi, Tim, I have both 64bit Windows 10 and Windows 7 at hands. I mainly use msys2, and in the mingw-w64 (not ucrt) target.

Quote from: ollydbg on August 25, 2024, 03:06:36 PM

Quote from: stahta01 on August 25, 2024, 04:05:54 AM

Quote from: ollydbg on August 25, 2024, 02:16:17 AM
Hi, this is a nice tool, and someone are using this tool to build C::B by the github action, you can see discussion here:

build bot in the github, I see one nice project (https://forums.next.codeblocks.org/index.php/topic,25856.0.html)

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

Hi, Tim, I have both 64bit Windows 10 and Windows 7 at hands. I mainly use msys2, and in the mingw-w64 (not ucrt) target.

https://github.com/stahta01/MINGW-packages/actions/runs/10543268999#artifacts (https://github.com/stahta01/MINGW-packages/actions/runs/10543268999#artifacts)

Link to 4 versions of untested packages.

These packages are autodeleted in time; I have no idea how long I think it was 90 days.

Tim S.

Quote from: stahta01 on August 25, 2024, 05:12:49 PM

https://github.com/stahta01/MINGW-packages/actions/runs/10543268999#artifacts (https://github.com/stahta01/MINGW-packages/actions/runs/10543268999#artifacts)

Link to 4 versions of untested packages.

These packages are autodeleted in time; I have no idea how long I think it was 90 days.

Tim S.

Thanks. I will try it, it looks like I need to use the pacman command to manually install this package.  :)

Oh, sorry, it looks like cbp2make is a plugin already in our C::B's code repo, so I can simply build it or use the nightly build version.  :(

Sorry about the noise.

EDIT:

cbp2make.exe is an standalone program, so I can directly call it.

I have added cbp2make to the msys2 mingw codeblocks package; so, the cbp2make.exe will in a few days be part of the codeblocks msys2 mingw package.