News:

As usual while waiting for the next release - don't forget to check the nightly builds in the forum.

Main Menu

cbp2make - makefile generation tool

Started by mirai, November 13, 2010, 10:27:15 PM

Previous topic - Next topic

mirai

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.

mirai

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.

mirai

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

mirai

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.


mirai

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.


mirai

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.

oswjk

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

stahta01

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

Should above end with a "/"?

Tim S
C Programmer working to learn more about C++.
On Windows 10 64 bit and Windows 11 64 bit.
--
When in doubt, read the CB WiKi FAQ. [url="http://wiki.codeblocks.org"]http://wiki.codeblocks.org[/url]

mirai

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

mirai

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

oswjk

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.

mirai

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.

mirai

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.

mirai

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.

Alpha

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).  What do other people think?