User forums > Using Code::Blocks

cbp2make - makefile generation tool

<< < (22/25) > >>

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:

--- Quote from: Alpha on March 14, 2015, 06:48:00 pm ---See attached.

--- End quote ---
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)
--- End code ---
- 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'
--- End code ---

--- 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
--- End code ---
- 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))
--- 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)
- 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. :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version