Code::Blocks Forums

User forums => Using Code::Blocks => Topic started by: mirai on November 13, 2010, 10:27:15 pm

Title: cbp2make - makefile generation tool
Post by: mirai on November 13, 2010, 10:27:15 pm
cbp2make is another standalone command-line tool to convert Code::Blocks projects to GNU makefiles.
Unlike previously appeared cbp2mak (v0.2) tool it does not require to be built for individual projects,
however, it is still in early stage of development and currently able to process only simple project files.
Hopefully, somebody will find this tool useful (http://sourceforge.net/projects/cbp2make (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.
Title: Re: cbp2make - makefile generation tool
Post by: xunxun on November 14, 2010, 09:26:09 am
That's very useful function, and you can refer to cbmakegen plugin.

http://forums.codeblocks.org/index.php/topic,6241.0.html
http://developer.berlios.de/projects/cbmakegen/
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 14, 2010, 12:57:01 pm
That's very useful function, and you can refer to cbmakegen plugin.

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

Thank you, xunxun1982, I will refer to that.

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

Quote
Usage syntax:

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

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

        Common options:
                cbp2make --verbose      // show project information
                cbp2make --quiet        // hide all messages
                cbp2make --help         // display this message
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 17, 2010, 02:33:38 am
Update: (see rev.30)



There's still a lot of work has to be done...
Title: Re: cbp2make - makefile generation tool
Post by: oBFusCATed on November 17, 2010, 08:57:10 am
mirai: Do you have plans to make automake/autotools system generation?
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 17, 2010, 08:56:20 pm
mirai: Do you have plans to make automake/autotools system generation?

Honestly, I just haven't thought about creating that kind of build tool.
As far as I know, the autotools system is rather complicated and unfriendly one.
However, If there is an actual necessity to connect CB to automake/autotools system,
maybe it is a good idea to get concerned about developing such tool.
For the time being, I want to get makefile generation tool to production state
as soon as possible before I am forced to switch to something else...
Title: Re: cbp2make - makefile generation tool
Post by: xunxun 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 19, 2010, 02:20:09 am
I think you can add Linux makefile/Mingw makefile(make/mingw32-make) and Windows makefile(nmake) support.

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

Update: (see rev.35)


.
Quote
Usage syntax:

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

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

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

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


Now I'm gradually starting to switch from developing to testing and working on compatibility with Windows.
There are few things I had problems with.
One problem is working directories for targets. According to CB's wiki, one should change directory to target's
working directory before building it, but applying that to the CB projects results in discrepancy in expected paths
in build command sequence. What's wrong?
Another is calling resource compilers, processing of WX forms, etc. How does CB invokes this resource compiler stuff ?
There are also few other things to implement before full-scale testing, but I think they will be completed in the course of time.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 20, 2010, 03:46:44 pm
Update: (see rev.37)



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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 21, 2010, 02:00:51 pm
Update: (see rev.38)



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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 23, 2010, 08:47:15 pm
Update: (see rev.39)


Title: Re: cbp2make - makefile generation tool
Post by: 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?
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 23, 2010, 10:15:45 pm
mirai: Do you use some version control system, because I couldn't find it in the project page on the sf.net?
Yes, I use Git locally, but I don't publish the repository, generally because I don't feel strong reason to do so (at least now).
And, since Git has no true revision numbers, I use following naming scheme: "project-branch-revision",
where "revision" is simply `git log --pretty=format:'%h' | wc -w` expression evaluated while switched to that branch.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on December 05, 2010, 03:28:27 am
Update: (see rev.42)



.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on December 11, 2010, 05:16:39 pm
Update: (see rev.53)


.
Quote
Usage syntax:

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

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

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

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

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


Support for other compilers and non-GNU tools (nmake, etc.) with totally different command syntax will be added later.
Title: Re: cbp2make - makefile generation tool
Post by: user601 on January 11, 2011, 10:06:41 am
Have you ever tried to compile this under windows (mingw)?
Title: Re: cbp2make - makefile generation tool
Post by: mirai on January 16, 2011, 08:59:23 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: 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.
Title: Re: cbp2make - makefile generation tool
Post by: MortenMacFly on January 20, 2011, 09:26:23 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).
Title: Re: cbp2make - makefile generation tool
Post by: MortenMacFly on January 20, 2011, 09:40:31 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:
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. ;-)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on January 21, 2011, 02:50:38 pm
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: MortenMacFly
It 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 13, 2011, 09:36:21 pm
Update: (see rev.66)



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.
Title: Re: cbp2make - makefile generation tool
Post by: 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 15, 2011, 07:13:08 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.
Title: Re: cbp2make - makefile generation tool
Post by: MortenMacFly on March 16, 2011, 01:47:51 pm
because they were just fine [not so] many revisions ago.
If you renamed your targets that that's the reason.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 23, 2011, 09:48:15 pm
Update: (see rev.80)



Title: Re: cbp2make - makefile generation tool
Post by: blinde on March 24, 2011, 11:15:29 am
Hi.

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

Thanks

Chris
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 24, 2011, 03:40:23 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: blinde on March 24, 2011, 04:10:03 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


Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 24, 2011, 04:59:40 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.

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.

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.
Title: Re: cbp2make - makefile generation tool
Post by: blinde on March 24, 2011, 05:35:29 pm
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):

Code
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 :


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

Title: Re: cbp2make - makefile generation tool
Post by: 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.
blinde: please use code tags in order to make your posts more readable
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 25, 2011, 02:58:09 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.
Title: Re: cbp2make - makefile generation tool
Post by: 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).
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 25, 2011, 05:04:38 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:


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.
Title: Re: cbp2make - makefile generation tool
Post by: oBFusCATed on March 25, 2011, 06:17:39 pm
So you'll rewrite depslib :lol:
Title: Re: cbp2make - makefile generation tool
Post by: Pecan on March 26, 2011, 03:58:07 pm
Something like the following might help you get the dependencies that CB already sets up.

Code
//----------------------------------------------------------------------------
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;
}
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 26, 2011, 05:46:15 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.
Title: Re: cbp2make - makefile generation tool
Post by: stahta01 on March 26, 2011, 10:18:30 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 27, 2011, 12:05:27 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on April 07, 2011, 03:45:17 am
Update: (see rev.91)



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).
Title: Re: cbp2make - makefile generation tool
Post by: adityagameprogrammer on April 14, 2011, 08:54:17 am
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
Code
#include <unistd.h>
in
Code
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 .
Title: Re: cbp2make - makefile generation tool
Post by: mirai on April 16, 2011, 12:45:29 am
Possible Bug:
i Assume this was due to missing header file. Hence i added it
Code
#include <unistd.h>
in
Code
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.
Title: Re: cbp2make - makefile generation tool
Post by: ripcordjones on April 20, 2011, 11:38:14 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on April 22, 2011, 07:24:28 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.
Title: Re: cbp2make - makefile generation tool
Post by: ripcordjones on April 23, 2011, 12:58:17 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on April 23, 2011, 02:21:15 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.

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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on April 27, 2011, 11:20:05 am
Update: (see rev.99) This is a major preliminary update prior to switching to multiple toolchain architecture.



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/)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 07, 2011, 09:51:32 pm
Update: (see rev.100) bugfix release


Title: Re: cbp2make - makefile generation tool
Post by: killerbot on May 09, 2011, 09:37:44 pm
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 :
Code
debug: before_debug out_debug after_debug

would become  (and all other likewise occurrences ) :

Code
Debug: before_Debug out_Debug after_Debug

What do you think ?
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 09, 2011, 10:11:20 pm
I have a cbp project, with the following targets : Debug and Release
I would expect the same casing is used :
Code
Debug: before_Debug out_Debug after_Debug
What 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?
Title: Re: cbp2make - makefile generation tool
Post by: 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 ;-)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 10, 2011, 10:55:42 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: killerbot on May 10, 2011, 01:03:03 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 10, 2011, 01:47:25 pm
Let me explain  : why I expected it to be default behavior. ...
Good point, I agree.

But 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...
Title: Re: cbp2make - makefile generation tool
Post by: killerbot on May 10, 2011, 02:27:25 pm
sounds good : target-case
Title: Re: cbp2make - makefile generation tool
Post by: oBFusCATed on May 10, 2011, 03:08:50 pm
I'm not a user of cbp2make, but I guess less options is better.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 12, 2011, 12:46:37 am
Update: (see rev.101)

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

Title: Re: cbp2make - makefile generation tool
Post by: mirai on June 20, 2011, 07:48:50 pm
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.



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
Title: Re: cbp2make - makefile generation tool
Post by: pacrook on July 15, 2011, 09:45:34 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on July 16, 2011, 08:49:50 am
Not 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on July 17, 2011, 11:44:32 am
Update: (see rev.109) a bugfix release



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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on July 19, 2011, 03:08:43 am
Update: (see rev.110) back from another bug hunt

Title: Re: cbp2make - makefile generation tool
Post by: mirai on July 26, 2011, 05:43:54 pm
Update: (see rev.112)



 
Title: Re: cbp2make - makefile generation tool
Post by: mirai on September 05, 2011, 07:16:11 pm
Update: (see rev.118)


 
 
Title: Re: cbp2make - makefile generation tool
Post by: mirai on October 18, 2011, 09:44:55 am
Update: (see rev.120)

Title: Re: cbp2make - makefile generation tool
Post by: 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:

Code
    <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:

Code
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:

Code
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:

Code
<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)\" />
    ...
Title: Re: cbp2make - makefile generation tool
Post by: stahta01 on November 24, 2011, 04:54:34 pm
Quote
<builtin base="/home/oskari/qt-4.7.4/"

Should above end with a "/"?

Tim S
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 24, 2011, 05:37:38 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 26, 2011, 12:21:15 pm
I think I solved this issue with global compiler variables, but I still need a .cbp file to test against it.

Also, would it be possible to define the $(PROJECT_NAME) and $(TARGET_NAME)? For example, I have the following in my .cbp:
Code
<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.
Title: Re: cbp2make - makefile generation tool
Post by: oswjk on November 27, 2011, 04:55:52 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 27, 2011, 05:00:36 pm
Update: (see rev.125)


Title: Re: cbp2make - makefile generation tool
Post by: mirai on November 29, 2011, 09:37:00 pm
Update: (see rev.127) a quick bugfix release

Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 18, 2012, 10:25:31 pm
Update: (see rev.130)



Try this revision if you previously experienced any problems with 'make' complaining about wrong paths.
Title: Re: cbp2make - makefile generation tool
Post by: Alpha on March 18, 2012, 11:59:40 pm
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?
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 30, 2012, 08:09:55 pm
Update: (see rev.133)


Title: Re: cbp2make - makefile generation tool
Post by: Lefteris on May 05, 2012, 07:49:00 am
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:
Code
cbp2make -in foo.cbp
The output I get is:
Code
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

Code
     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.
Code
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.
Code
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)
 
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 07, 2012, 02:14:07 am
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
Title: Re: cbp2make - makefile generation tool
Post by: 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 07, 2012, 10:30:22 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  :(.
Title: Re: cbp2make - makefile generation tool
Post by: stahta01 on May 08, 2012, 03:48:45 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on May 10, 2012, 05:01:59 pm
Update: (see rev.135)


Title: Re: cbp2make - makefile generation tool
Post by: mirai on September 02, 2012, 11:36:26 am
Update: (see rev.137)


Title: Re: cbp2make - makefile generation tool
Post by: axus on September 08, 2012, 08:30:30 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on September 14, 2012, 12:05:12 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. :)
Title: Re: cbp2make - makefile generation tool
Post by: Kenneth McGregor on December 13, 2012, 04:08:21 pm
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
Title: Re: cbp2make - makefile generation tool
Post by: oBFusCATed on December 13, 2012, 04:18:44 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?
Title: Re: cbp2make - makefile generation tool
Post by: Kenneth McGregor on December 13, 2012, 04:29:20 pm
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
Title: Re: cbp2make - makefile generation tool
Post by: Kenneth McGregor on December 13, 2012, 09:33:18 pm
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
Title: Re: cbp2make - makefile generation tool
Post by: mirai on December 26, 2012, 08:32:08 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on February 02, 2013, 12:55:40 am
Update: (see rev.138) a small bugfix release

Title: Re: cbp2make - makefile generation tool
Post by: freq on June 01, 2013, 10:46:49 am
Can anyone explain tom how to use this tool?
Title: Re: cbp2make - makefile generation tool
Post by: stahta01 on June 01, 2013, 06:37:37 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mcwanghui on June 02, 2013, 12:29:07 pm
great work! thank you very much!
Title: Re: cbp2make - makefile generation tool
Post by: mirai on June 09, 2013, 09:16:41 am
Update: (see rev.147) an intermediate release



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.
Title: Re: cbp2make - makefile generation tool
Post by: veneff on December 09, 2013, 03:55:52 pm
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
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 10, 2014, 10:40:58 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: Dvorkin on March 18, 2014, 01:07:11 pm
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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 19, 2014, 10:12:14 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: the.sniffer on December 28, 2014, 01:14:39 am
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).
Title: Re: cbp2make - makefile generation tool
Post by: mirai on January 04, 2015, 07:21:13 pm
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)
Title: Re: cbp2make - makefile generation tool
Post by: the.sniffer on January 10, 2015, 10:55:29 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: m.rap on January 21, 2015, 06:10:07 am
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".
Title: Re: cbp2make - makefile generation tool
Post by: fruitCode on February 24, 2015, 11:11:46 am
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)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 14, 2015, 02:11:03 pm
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
Code
        <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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 14, 2015, 02:31:00 pm
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) ?
Title: Re: cbp2make - makefile generation tool
Post by: Alpha on March 14, 2015, 06:48:00 pm
See attached.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on March 14, 2015, 07:56:50 pm
See attached.
Great! Thanks a lot!
Title: Re: cbp2make - makefile generation tool
Post by: White-Tiger on June 09, 2015, 04:37:50 pm
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:
Code: make
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:
Code: make
Makefile:457: warning: overriding recipe for target '.obj\\common\\clock.o'
Makefile:383: warning: ignoring old recipe for target '.obj\\common\\clock.o'
Code: make
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
Code: c
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)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on June 22, 2015, 07:00:45 am
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. :)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on June 22, 2015, 09:50:31 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.

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

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

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

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

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

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.

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

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

- "option_wingui" should work for any platform. Currently it's wrapped around an
Code: c
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?

- 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.
Title: Re: cbp2make - makefile generation tool
Post by: mirai on June 24, 2015, 07:00:36 pm
White-Tiger, can you send me some .cbp files for testing?
Please leave them here in attachment or send to mirai.computing@gmail.com
Title: Re: cbp2make - makefile generation tool
Post by: White-Tiger on June 30, 2015, 01:33:05 am
- 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...)


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


- 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


- "option_wingui" should work for any platform. Currently it's wrapped around an
Code: c
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
Code: bash
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)
Title: Re: cbp2make - makefile generation tool
Post by: mirai on July 25, 2023, 10:35:14 am
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.
Title: Re: cbp2make - makefile generation tool
Post by: cacb on July 26, 2023, 11:23:19 am
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.


Title: Re: cbp2make - makefile generation tool
Post by: MortenMacFly on July 26, 2023, 08:21:19 pm
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.

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.

Q2: Who should do built-in variable expansion, cbp2make while generating a makefile or Make while building stuff?
My preference: Again option 1.

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