User forums > Using Code::Blocks
cbp2make - makefile generation tool
mirai:
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- Would be nice if I could just use those post-build steps:
--- End quote ---
Yes, good example, I also need macros like these for microcontroller firmware projects.
Another major drawback is that cbp2make is not importing compiler configuration from C::B in any way.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- The current version fails to create virtual targets... basically it only ever creates the first virtual target. (which is one reasons I can't use it)
--- End quote ---
Oh, that's interesting. Virtual targets are supported but I can't see them in my makefiles.
Probably they are filtered out my mistake during platform compatibility checking. Should be easy to fix.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- Targets cannot share object files... at least not without warnings such as:
--- End quote ---
They shouldn't share them. I personally consider this a poorly configured project.
To enable shared object files between targets one should at first verify that the build options for these files are effectively equal between targets.
Otherwise you're messing up your project by mixing in possibly incompatible object files.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- I would also love if virtual targets wouldn't be prefixed "virtual_". I guess no one wants to "make virtual_debug" when it could be "make debug" or "make release" or even "make all" (that is, allow a virtual "all" target to overwrite default "all")
--- End quote ---
OK, I agree to make this configurable. This was initially done to resolve name conflicts between default and virtual targets.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- cbp2make doesn't properly append target options to project global ones.. It creates code like this: "$(LIB0)-lComctl32", notice the missing space.
--- End quote ---
There were such issues before, but they should be already fixed by now. Does this bug still occur?
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- clean fails if a directory or file was already "cleaned" and no longer exists... it doesn't properly handle shared object as well, because it tries to remove the object directory which might still contain objects..
--- End quote ---
This follows exactly from the same rule that object files must not be shared between targets.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---And about Sourceforge... why not just move on to GitHub or GitLab ;)
--- End quote ---
Actually I'm using Git internally and some other Git-related gear for managing projects.
However, the original repository also contains things I can't share. Sorry about that.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- "use target options only" doesn't always work.. seems to work for compiler options and some linker options, but not for link libraries
--- End quote ---
AFAIR, that's probably because libraries are processed in a different way.
Can't tell for sure, haven't seen the code for a while.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- "target_extension"/"library_extension" config option is totally ignored. At least for "executable_binary_linker" and "dynamic_library_linker" because cbp2make only ever uses AutoFileExtension() which doesn't use "target_extension" at all and returns the target OS' default
--- End quote ---
I don't remember now why it is this way. Maybe just an incomplete implementation. Need to take a look at the code.
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- "option_wingui" should work for any platform. Currently it's wrapped around an
--- Code: (c) ---if ((pl->OS()==CPlatform::OS_Windows) && (target->Type()==CBuildTarget::ttExecutable))
--- End code ---
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)
--- End quote ---
AFAIR I considered that this kind of cross-platform builds is next to nonexistent.
Do you build Windows applications on Linux/Mac/... with native tools and foreign libraries?
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- if make is called with -j 4 to use parallel-builds, post-build steps might fail because they don't depend on the base build step (out_*)
though, it seems like cbp2make knew about this issue when it created "out_*" steps as they depend properly on "before_*" (pre-build)
--- End quote ---
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:
--- Quote from: mirai on June 22, 2015, 09:50:31 pm ---
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- Targets cannot share object files... at least not without warnings such as:
--- End quote ---
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.
--- End quote ---
actually a reason why targets should be able to share them.
One project usually got the very same compiler options, if you're forced to split it into different projects so that make files are properly generated, it's way more likely to have incompatible compiler flags...
And sharing the very same source files shouldn't be a problem as well... In case you're compiling multiple programs that share some common code. (ok, one could use different object directories...)
--- Quote from: mirai on June 22, 2015, 09:50:31 pm ---
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- cbp2make doesn't properly append target options to project global ones.. It creates code like this: "$(LIB0)-lComctl32", notice the missing space.
--- End quote ---
There were such issues before, but they should be already fixed by now. Does this bug still occur?
--- End quote ---
I'm always using the latest versions before I report stuff.. besides I'm generally always using (and checking for) the latest version before I use a program.
And your latest release is rev147 which is 2 years old.
--- Quote from: mirai on June 22, 2015, 09:50:31 pm ---
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- clean fails if a directory or file was already "cleaned" and no longer exists... it doesn't properly handle shared object as well, because it tries to remove the object directory which might still contain objects..
--- End quote ---
This follows exactly from the same rule that object files must not be shared between targets.
--- End quote ---
Untrue, this issue doesn't exist on Linux. *nix generated makefiles use "if"'s before trying to delete files. Windows does not.
This basically means that you can't "make clean" twice, or can't use it on a clean checkout of a repository.. (just to make sure everything is cleaned)
It shouldn't fail though. Trying to delete a file that doesn't exist, still means that the file is successfully deleted / non-existent and the result is the expected clean state
--- Quote from: mirai on June 22, 2015, 09:50:31 pm ---
--- Quote from: White-Tiger on June 09, 2015, 04:37:50 pm ---- "option_wingui" should work for any platform. Currently it's wrapped around an
--- Code: (c) ---if ((pl->OS()==CPlatform::OS_Windows) && (target->Type()==CBuildTarget::ttExecutable))
--- End code ---
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)
--- End quote ---
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?
--- End quote ---
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
--- End code ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version