BlackDoc documentation plugin

[marked]

Hi! I'm new here, so, firstly, thanks to the C::B team for the great IDE!

I want announce the plugin I am creating. This is the documentation generator, but it generates the documentation not from the source code comments, but from text files, which are separated from sources. These files can be written using the wiki-style markup language. Currently, the plugin supports only the output to HTML. This plugin may also be used not only for documentation purposes, but it was the main goal of creating it.

The very first usable version of BlackDoc is available.

I uploaded this project to Google Code, here is the link to the project page: http://code.google.com/p/blackdoc/
Source code versions are managed using Mercurial (hg): http://code.google.com/p/blackdoc/source/checkout

Also, here is the large description of this plugin, the page was generated by the plugin itself, without any additional changes: http://blackdoc.googlecode.com/hg/documentation/html/help/description-en.html

Plugin was written using C::B svn7899 version, C::B SDK 1.11.18, Linux Mint Debian Edition. It is also necessary to use the c++0x compiler flag.

Currently I need some feedback/testing/bugreports etc. And it would be pleasant, if someone could test the plugin on windows, and, maybe, on Mac.

Sorry for errors, my English is still not good enough.

edit: some misleading info was corrected

[MortenMacFly]

Sounds interesting, but I don't get it compiled at all. The compiler freaks out completely. I am using TDM's GCC 4.6.1 but even with or without the C++11 compiler flag - no way. If you provide a working Windows version I guess you'll reach a broader audience - it should really be cross-platform. (I've made myself windows project files btw.)

Why do you need C++11? Is is only due to random numbers, or any more constraints? You put hard requirements here that might not be needed I think...

[oBFusCATed]

Random numbers are present in TR1...

@marked:
1. You don't need the .depend file in the VCS, it is created automagically...
2. Can you add an autotools build system?
    You can use the plugins at svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbm and svn://cmpt.benbmp.org/cb_editor_navigation
    to see how can you do it, if you are not that familiar with autotools.

[marked]

@MortenMacFly
Sorry for the misleading, that was c++0x flag actually. But on Windows, as I know, it is necessary to use the gnu++0x flag.

I used the std::unique_ptr and some nice features like "delete" to disable copy-ctor and also the "auto" keyword instead of writing the full iterator type.

I don't have windows installation right now, and no free space on my hard-drive to install it actually, so providing the windows version by me is a little bit difficult. Ok, maybe, when ubuntu 12.04 will be released, I'll try to install them both instead of LMDE...

@oBFusCATed
1) Removed.
2) Yes, you are right, I'm not familiar with autotools. I'll give it a go, but... is it really necessary? Why just not to build C::B using C::B?

svn claimed the first link as non-existant, the second worked.

[ollydbg]

svn claimed the first link as non-existant, the second worked.

The first svn address is:

Code

svn://cmpt.benbmp.org/cb_gdb_mi/debbugger_gdbmi

[marked]

@ollydbg
Thank you, this worked.

[MortenMacFly]

@MortenMacFly
Sorry for the misleading, that was c++0x flag actually. But on Windows, as I know, it is necessary to use the gnu++0x flag.

I figured that out myself... ;-) However - it does simply not compile under Windows at all. I've attached by project file for those willing to try.

BTW: you don't necessarily need to install Windows - cross compilation from Unix to Windows using MinGW works just fine (unfortunately this is not true for cross compiling from Windows to Linux).

[oBFusCATed]

2) Yes, you are right, I'm not familiar with autotools. I'll give it a go, but... is it really necessary? Why just not to build C::B using C::B?

In order to have a way to manage your OS install in the long run?
Keep in mind that some people use nightlies, thus the API is not stable and when you upgrade your C::B you have to recompile all the plugins.
If autotools is working making packages for the main distros is pretty simple.

p.s. If you really want this plugin to be used by more people you'll have to remove all the c++11 parts and make the project compilable by gcc4.1.2
(the main compiler for centos/redhat <6 on centos/redhat>6 you have gcc-4.4).

[marked]

@oBFusCATed
I added the bootstrap, configure.ac and Makefile.am to the project. Suddenly, I can't test them, because I am missing AM_OPTIONS_WXCONFIG, AM_PATH_WXCONFIG, maybe something else too. So they are untested and may be wrong. I think, I will not be able to test them in the near future.

No, sorry, I think, I will never understand people, who prefer to build something from sources/via command-line instead of using the GUI. I'll better stop to discuss this.

As of removing c++11 code... I like C++11. Of course I want people to use this plugin, but if I need to support old compilers... Really, I don't know, I need a time to think about this.

@MortenMacFly
This is not a big problem for me to install Windows. Maybe, I will do this next weekend. But then I will need to build the C::B from sources...

[oBFusCATed]

marked: Do you have wxgtk-devel/dev packages?

Unfortunately c++11 is unusable in large open source projects at the moment.

See here how to link to a nightly build on windows: http://wiki.codeblocks.org/index.php?title=Linking_the_plugin_to_a_Nightly_Build

[Alpha]

As of removing c++11 code... I like C++11. Of course I want people to use this plugin, but if I need to support old compilers... Really, I don't know, I need a time to think about this.

I would think that it is not necessary to completely remove it; only supply a build-able (if somewhat less functional) version for those who cannot or do not want to enable C++11.

Code

#ifdef __GXX_EXPERIMENTAL_CXX0X__

#else

#endif

Attached is a cbp to build this plugin on Windows.

[oBFusCATed]

Alpha, I doubt he can make a buildable versions without std::unique_ptr and why bother maintaining two versions...

p.s. People should be shot when they use internal gcc definitions!

[Alpha]

Alpha, I doubt he can make a buildable versions without std::unique_ptr and why bother maintaining two versions...

Hmm, I probably should have actually looked at the source before suggesting that.

p.s. People should be shot when they use internal gcc definitions!

I guess that means I need to go into hiding now .  *Puts on black sunglasses.*

[marked]

@oBFusCATed
Ok, I got it. The wxgtk-devel isn't available by me from repos. But I have read somewhere, that I need only the wxwin.m4 file. So, I downloaded the wxgtk-devel rpm-package with the version near to the wxWidgets version I have installed, and then I just copied the wxwin.m4 from it to /usr/share/aclocal/ folder. And it worked. Now the plugin can be built and installed using autotools. The sources on googlecode are already updated.

The gnu++0x flag is now also added to the cbp too, instead of c++0x.

Thanks for the link, I will add it to my bookmarks.

@Alpha
Yes, I think that I need just to rewrite the unique_ptr class 'by hand'. As oBFusCATed pointed me, the random numbers are available in tr1. And as of other features I have used  - it is simple to replace them with the 'old' C++ code.

As I understand, the plugin is nevertheless buildable on WIndows?

[Alpha]

As I understand, the plugin is nevertheless buildable on WIndows?

Yes; compiled and tested on XP with the project file from my previous post.