In order to make DoxyBlocks portable, could the paths to the documentation executables in the general preferences screen be made to use Codeblocks variables? The paths to the tools could then be made relative to the CB installation.

As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exerather than E:\Program Files\codeblocks\tool\Graphviz\bin\dot.exe as the path would make doxyblocks usable in a portable CB installation.Thanks.

I was wondering whether it wasn't simpler just to add the required paths to the system path, which is catered for already, however see my response to Morten's follow-up.

As an example being able to enter something like $(CODEBLOCKS)\tool\Graphviz\bin\dot.exe

@Cryogen: True, you can achieve that easily using a call to macros manager before applying the path's. It's a one-liner per path.

OK, cool. I will look at this because I like to build in as much flexibility as possible and, in general, it seems like a good idea.I guess that having to add to system paths could be a bit of a nuisance and having another option is definitely a "good thing".

I also had the DoxyBlocks-plugin in a CamelCase-named suubdirectory and only changed it to lower-case, because your svn-directory is in lower-case too.The contrib-plugins not all use CamelCase (even if I prefer it as you can see at my "own" plugin IncrementalSearch).

OK, I think I see how that happened. the SourceForge unix name for the project is "doxyblocks" even though the project name is "DoxyBlocks". I used lower case reflexively when I set it up and it can't be subsequently changed. I can see how that could cause confusion. However, the directory you check out into is named by the user so we just have to educate users until it becomes part of contrib, I think.

I have a small feature request: is it possible to add the doxygen flags EXTRACT_PRIVATE and EXTRACT_STATIC explicitly to the "Doxygen Defaults" tab? Although I never check EXTRACT_ALL, the setting is overriden by them, and I would like to have control over the documentation of private class members.

Of course, I can easily edit the generated doxygen settings file to this end, but it would make a big difference for me if I could have it generated the way I need it from the get-go.

Certainly, yes. It'll give me something to do today. I'll report back when it's in SVN.

Jens' patch doesn't update the Windows workspace for contrib plug-ins. To do so you need to do a few things:

1.Add DoxyBlocks' project to the contrib plugins workspace manually.

Now, because my installation doesn't match what C::B expects and config doesn't build the wx library with the name it expects (anyone care to advise me on this?)...

2.Open DoxyBlocks' build settings, select the "default" build and then the "Linker settings" tab and change the first entry under "Link libraries:" from "wx_msw$(WX_SUFFIX)-2.8.dll" to "wxmsw28$(WX_SUFFIX)".

If you have used a different wx library pattern on your system, replace mine with that.

3.Open the "Search directories" tab and on the "Compiler" sub-tab change "$(#wx.lib)\wx\include\msw-unicode-release-2.8" to "$(#WX.lib)\gcc_dll$(WX_CFG)".

Again, if your wx build directory tree is different, use the correct pattern for your installation.

Finally, for consistency with the other projects...

4.Open the "Pre/post build steps" tab and remove the line that starts "zip -j9 DoxyBlocks.cbplugin ..." from the "Post-build steps" window, unless you want the .cbplugin to be built, and check the checkbox at the bottom entitled "Always execute, even if target is up-to-date".

You should now be able to build DoxyBlocks with the other contrib plug-ins in a consistent way.

Cheers,

Gary.

[EDIT:] Do this, too, so that you can debug the plug-in from the contrib workspace:

Hi Morten,. . .OK, cool. I will look at this because I like to build in as much flexibility as possible and, in general, it seems like a good idea.I guess that having to add to system paths could be a bit of a nuisance and having another option is definitely a "good thing". . . .

Thanks for this Gary.I don't think adding to the CB-internal system path instead would really be a nuisance, but, since they are there already, your 4 or 5 paths to the executables are a useful reminder to nubies of the tool requirements of doxygen.

Released version 1.3.236 of DoxyBlocks-Added: Configuration of EXTRACT_PRIVATE and EXTRACT_STATIC. Requested by ptDev.-Updated: Changed the generated doxyfile to doxygen 1.6.3.-Updated: For consistency, changed HTML_TIMESTAMP default to YES.-Updated: For consistency, changed EXTRACT_LOCAL_METHODS default to NO.-Added: Macro expansion in path prefs so that you can use things like "$(CODEBLOCKS)" in paths. Requested by Codeur.

I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

I have also updated the generated doxyfile to version 1.6.3. I checked through the current default values set by Doxygen and changed those mentioned to match doxygen's defaults. The timestamp is useful and local methods are only useful for Objective C users. DoxyBlocks inherited settings from jomeggs' script, which was not configurable and therefore set some default values that were thought to be widely used. Most of those are configurable in DoxyBlocks. The remaining settings that are not set to doxygen's defaults and not configurable in DoxyBlocks are:

Setting

Purpose

Value

FULL_PATH_NAMES

Prepend the full path before files name in the file list

NO

GENERATE_TREEVIEW

Generate index tree view in side panel

YES

CALL_GRAPH

Have dot generate a call dependency graph

YES

The purest way to do things would be to provide configuration for any setting that is not set to doxygen's default. I think that those three settings are pretty fair as they are but some folks might prefer other settings. Should these be set to doxygen's defaults and accessible via doxywizard? Should these, or other settings, be added to DoxyBlocks configuration panel? Does anyone have any thoughts on this?

I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

After a quick check, the executable paths using CB variables in "preferences" work well for me too. Many thanks.I can place a portable CB based on BN 6190 onto a USB HDD and get DoxyBlocks to work immediately on any XP SP3 computer around (I cannot test on other systems).

I canīt still install ya pluginand in sourceforge i see only version 1.2.209

could anybody illuminate me

Gary is currently trying to get a CB install that will allow him to produce .cbplugin (s) that work for all of us. He is making good progress, but until he succeeds we build DoxyBlocks from subversion with modified projects on our own systems in order to test working plugins on our systems (the possibility of having the doxygen plugin on the next release is what motivates us to test it in these conditions despite the inconvenience). The SVN on SourceForge is at version 1.3.236.

Released version 1.3.236 of DoxyBlocks-Added: Configuration of EXTRACT_PRIVATE and EXTRACT_STATIC. Requested by ptDev.(...)I have added the features requested by ptDev and Codeur. Let me know how they go for you, guys. They worked well here.

Working fine here, too. Right now, your plugin is PERFECT for me. Thank you very much!

After a quick check, the executable paths using CB variables in "preferences" work well for me too. Many thanks.I can place a portable CB based on BN 6190 onto a USB HDD and get DoxyBlocks to work immediately on any XP SP3 computer around (I cannot test on other systems).

Gary is currently trying to get a CB install that will allow him to produce .cbplugin (s) that work for all of us. He is making good progress, but until he succeeds we build DoxyBlocks from subversion with modified projects on our own systems in order to test working plugins on our systems (the possibility of having the doxygen plugin on the next release is what motivates us to test it in these conditions despite the inconvenience). The SVN on SourceForge is at version 1.3.236.

Actually, I'm not. I'm of the opinion it's not worth the effort and, as Jens pointed out, too dependent on library versions and other factors. In other words, nice idea but it's broke. However, if you were to build it yourself in your C::B installation, the .cbplugin it generates might work for you. If not, you're back to building it with C::B.

Actually, I'm not. I'm of the opinion it's not worth the effort and, as Jens pointed out, too dependent on library versions and other factors. In other words, nice idea but it's broke. However, if you were to build it yourself in your C::B installation, the .cbplugin it generates might work for you. If not, you're back to building it with C::B.

I feel that there could be some confusion here between the concept of publishing an ideal .cbplugin that could work on any past and future builds of Code::Blocks (that obviously cannot work), and the concept of publishing source code and a project file producing a .cbplugin that would work on an official release and could be maintained for nightlies. One such official release is in preparation at this time. I may be mistaken, but I think LordCB is currently testing for that purpose.

However I am out of my depth here and will let the maintainers speak to us on that.

I feel that there could be some confusion here between the concept of publishing an ideal .cbplugin that could work on any past and future builds of Code::Blocks (that obviously cannot work), and the concept of publishing source code and a project file producing a .cbplugin that would work on an official release and could be maintained for nightlies. One such official release is in preparation at this time. I may be mistaken, but I think LordCB is currently testing for that purpose.

However I am out of my depth here and will let the maintainers speak to us on that.

Mmm, LordCB isn't a maintainer, I think he's just trying to install the plug-in. Creating a .cbplugin from the release code might work but that would be redundant, wouldn't it, as it would be in the contrib plug-ins (I hope)? :wink: