Author Topic: cbp2make - makefile generation tool  (Read 131380 times)

Offline mirai

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: cbp2make - makefile generation tool
« Reply #105 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) ?

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: cbp2make - makefile generation tool
« Reply #106 on: March 14, 2015, 06:48:00 pm »
See attached.

Offline mirai

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: cbp2make - makefile generation tool
« Reply #107 on: March 14, 2015, 07:56:50 pm »
See attached.
Great! Thanks a lot!

Offline White-Tiger

  • Multiple posting newcomer
  • *
  • Posts: 83
Re: cbp2make - makefile generation tool
« Reply #108 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: GNU make
  1. objcopy --only-keep-debug $(TARGET_OUTPUT_FILE) $(TARGET_OUTPUT_DIR)$(TARGET_OUTPUT_BASENAME).dbg
  2. 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: GNU make
  1. Makefile:457: warning: overriding recipe for target '.obj\\common\\clock.o'
  2. Makefile:383: warning: ignoring old recipe for target '.obj\\common\\clock.o'
Code: GNU make
  1. 383: $(OBJDIR_CALENDAR)\\common\\clock.o: common\\clock.c
  2.         $(CC0) $(CFLAGS_CALENDAR) $(INC_CALENDAR) -c common\\clock.c -o $(OBJDIR_CALENDAR)\\common\\clock.o
  3. 457: $(OBJDIR_APP)\\common\\clock.o: common\\clock.c
  4.         $(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
  1. 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)
« Last Edit: June 16, 2015, 11:59:29 am by White-Tiger »
Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

Offline mirai

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: cbp2make - makefile generation tool
« Reply #109 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. :)

Offline mirai

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: cbp2make - makefile generation tool
« Reply #110 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
  1. 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.

Offline mirai

  • Multiple posting newcomer
  • *
  • Posts: 101
Re: cbp2make - makefile generation tool
« Reply #111 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

Offline White-Tiger

  • Multiple posting newcomer
  • *
  • Posts: 83
Re: cbp2make - makefile generation tool
« Reply #112 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
  1. 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
  1. cd ./Source
  2. # Make a copy of the manually fixed "Makefile.unix"
  3. 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)
« Last Edit: June 30, 2015, 01:38:22 am by White-Tiger »
Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)