cbp2make - makefile generation tool

[mirai]

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

[Alpha]

See attached.

[mirai]

See attached.

Great! Thanks a lot!

[White-Tiger]

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)

[mirai]

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.

[mirai]

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

[mirai]

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

[White-Tiger]

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

[mirai]

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.

[cacb]

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.

[MortenMacFly]

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

[ollydbg]

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

build bot in the github, I see one nice project

Nice work!

EDIT:

Where can I find the binary file of this tool?

[stahta01]

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

build bot in the github, I see one nice project

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

[ollydbg]

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

build bot in the github, I see one nice project

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

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

[stahta01]

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

build bot in the github, I see one nice project

Nice work!

EDIT:

Where can I find the binary file of this tool?

What OS? If Windows MSys2, what environment?

Tim S.

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

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

Link to 4 versions of untested packages.

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

Tim S.