Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Doxygen plugin

<< < (7/53) > >>

MortenMacFly:

--- Quote from: Cryogen on March 05, 2010, 09:28:52 pm ----Added: Inserted comments blocks are now indented to match the code that they're commenting.

--- End quote ---
Can't wait testing... :-)

Looks REALLY good so far... Good work! :P

codeur:
DoxyBlocks builds in the trunk development environment, except that it attempts to link with -lwx_mswu-2.8.dll which is not in my system. I have to link with -lwxmsw28u (wxmsw28u.dll which I have) instead. Once I link it this way, it runs OK in the trunk version of CB (still cannot get it to load in our svn 6113 production system unfortunately, but I am getting closer).

I am totally unfamiliar with CB development so I have this newbie question for you Gary: is "libwx_mswu-2.8.dll.a" or "wx_mswu-2.8.dll" a file we are supposed to obtain from building the wxwidgets or during their installation?

BTW: I am impressed by the amount of work you have produced for this doxygen plugin in this short time... and you are a perfectionist, fixing details before they are mentioned to you. I am feeling quite awed really, thanks.

private_joker:
Bug: if tabs w. sourcecode isn't open and you trying push "Extract documentation..." button, CB will crash.

Bug: ExtractDocs.cpp:551


--- Code: ---ret = wxExecute (cmd + wxT(" ") + fnDoxyfile.GetFullPath(), sOutput, sErrors);
if(ret == 0)
 {}

--- End code ---


--- Quote ---Execution of 'C:\Program Files\doxygen\bin\doxygen.exe' failed.

--- End quote ---

It seems like "if(ret == 0)" isn't fully correct. Maybe better use "if(ret != -1)"

Probably Bug: doxywizard isn't run.


--- Quote ---Running doxywizard...
Process 3308 (C:\Program Files\doxygen\bin\doxywizard.exe C:\Program Files\CodeBlocks\workspace\Codeblocks-Nightly\src\plugins\contrib\doxyblocks\doxygen\doxyfile) launched.

--- End quote ---

I'm using self builded CB and self builded Doxyblocks. Both from SVN trunk.

Thank you & keep working on it.


Cryogen:

  Hey Codeur,


--- Quote from: codeur on March 05, 2010, 11:56:24 pm ---DoxyBlocks builds in the trunk development environment, except that it attempts to link with -lwx_mswu-2.8.dll which is not in my system. I have to link with -lwxmsw28u (wxmsw28u.dll which I have) instead. Once I link it this way, it runs OK in the trunk version of CB (still cannot get it to load in our svn 6113 production system unfortunately, but I am getting closer).

--- End quote ---

That sounds fine. There are still some subtleties of building in C::B that I haven't yet mastered. I tried removing ".dll" from my build settings and it builds just fine. I can see from the output that it links to the same file. C::B does have a system that adds prefixes and suffices to library names. The ".dll" is obviously unnecessary. Much of what I have set up is garnered from other plug-ins. Looking at the latest SVN, I see that plug-ins are set up with the lib described like this : "wxmsw28$(WX_SUFFIX)" where WX_SUFFIX = "u". I am gradually homing in on the correct settings to match the default set in the C::B code but I still have the problem that I have been unable to find any way to build wx with the "gcc_dll" style path. Until I can get that set up I won't be able to match C::B exactly, however I think that this is mostly obscured by the $(WX) variable. I will look at improving my library naming scheme as per the contrib plug-ins.

I haven't tried anything below 6130 and I'm now using 6182.  :)


--- Quote from: codeur on March 05, 2010, 11:56:24 pm ---I am totally unfamiliar with CB development so I have this newbie question for you Gary: is "libwx_mswu-2.8.dll.a" or "wx_mswu-2.8.dll" a file we are supposed to obtain from building the wxwidgets or during their installation?

--- End quote ---

When you build the plug-in, it links with your build of wx, i.e. you need to either build it yourself or download some pre-compiled libs. See http://wiki.codeblocks.org/index.php?title=Compiling_wxWidgets_2.6.2_to_develop_Code::Blocks_%28MSW%29. It's a bit out of date re: wx but still useful. I heartily recommend building it as it gives you much more control. C::B will prefix "libwx_" and postfix ".a" (and apparently ".dll") to the name in build settings so you should only need to enter "wx_mswu-2.8". The one thing I'm not certain of yet is whether "wxmsw28$(WX_SUFFIX)" expands to "mswu-2.8" or "msw-2.8u". I will find out shortly.  :wink:


--- Quote from: codeur on March 05, 2010, 11:56:24 pm ---BTW: I am impressed by the amount of work you have produced for this doxygen plugin in this short time... and you are a perfectionist, fixing details before they are mentioned to you. I am feeling quite awed really, thanks.

--- End quote ---

Thanks.  8)
Coding is "what I do" so I like it and this is my pet project at the moment. And yes, I'm a perfectionist.
I'm using it every day, as well, so it gets a good workout.

Cheers.

Cryogen:

--- Quote from: MortenMacFly on March 05, 2010, 09:55:38 pm ---
--- Quote from: Cryogen on March 05, 2010, 09:28:52 pm ----Added: Inserted comments blocks are now indented to match the code that they're commenting.

--- End quote ---
Can't wait testing... :-)

Looks REALLY good so far... Good work! :P

--- End quote ---

Thanks Morten. I'm hoping to get it into the contrib collection so please let me know if there is anything I need to do before that can happen e.g. setup, standards, build settings, etc.

I still have a couple of things in mind. I have realised that the current configuration scheme won't work well across projects. All settings are global at the moment which means that settings such as project version, comment style, doxyfile defaults, etc., which should be per-project settings, will carry over to subsequent projects. I am going to change that today so that those items are stored per-project in the .cbp. Settings such as paths to executable files can and should remain global.
I would also like to look at automating comment insertion across whole files and, if that's practical, perhaps across whole projects. That does raise some issues, though, such as how to differentiate between a function definition in a .cpp and the prototype in a .h and avoid commenting them both. My current thinking is that commenting a whole file is probably as far as I should go.
I also want to improve the regexes. I have detection of multiple return vals working in the regex testbed but it fails in the code. I don't understand that as the testbed is built with the same wx and therefore uses the same function calls. Any ideas?

Cheers,

  Gary.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version