about the errors and warnings...

Hi all,

I have another issue with my documentation: I would like to classify the 
errors (like warning, serious, critical) and present it in a display.. 
the log is just plain txt.. there is also some xml output available?

thanks in advance for any help,

Pablo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Matlab frontend

After reading through the mailing list seeking for a
matlab frontend to doxygen I encountered some related
messages, unfortunately these are from 2 years back.

Is there any progress in a matlab frontend ? As
currently tools are quite lacking in generating good
dependencies and html output for matlab (with support
for matlab's pseudo classes and inheritance.)

Is adapting Octave's lexer and parser files a
possibility. Shouldn't be too hard I think, except for
converting the structure into Doxygen's C++ class
tree.

kind regards,
ilm

      __________________________________________________________
Sent from Yahoo! Mail - a smarter inbox http://uk.mail.yahoo.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Failed compilation on OS X (10.4.11)

Hi all

The doxygen-1.5.5 fails to compile on OS X 10.4.11.

qfiledefs_p.h:258: error: field 'st' has incomplete type
{standard input}:unknown:FATAL:can't create output file: ../objects/qfile.o
make[1]: *** [../objects/qfile.o] Error 1
make: *** [all] Error 2

Source was taken from doxygen-1.5.5.src.tar.gz.

Cause seems to be failure to include <sys/stat.h> in qtools/qfiledefs_p.h

Attached patch allows MAC_OS_X_VERSION_10_4 to include  <sys/stat.h> as it
is done for MAC_OS_X_VERSION_10_5.
I don't know if that is correct fix, because there is some definition of
_OS_UNIX_ in the same block.

Jan

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Doxygen-develop mailing list

Doxygen 1.5.5 breaks partial include paths

Hello Doxygen devs.

We have a source tree which has another project inside. Within this
project tree again includes of the form <extproject/dir/file.h> relative
to this projects root. With doxygen 1.5.5 this breaks, astonishingly
only for a few files and not all (which probably has something to do
with the caching but I can't tell).

What I can tell is that the problem is related to src/util.cpp line 4472.

There fdStripPath is compared to pathStripped. Our strip paths are empty
so nothing actually happens to the paths. But pathStripped contains the
relative path very similar to the include mentioned above. For that
include it would be "extproject/dir". But fdStripPath (is the absolute
path, for example something like "/home/tim/project1/extproject/dir".
The comparison now obviously fails and the file is not found.

To fix this I modified line 4471 to read:
QCString fdStripPath =
stripFromIncludePath(fd->getPath().right(path.length()));

".right(...)" has been added to take only part of the path which has the
same length as the path we compare against effectively using only the
relative path. This is more similar to what it used to be in 1.5.4.

Also I noticed that before the upgrade we could have in the .cpp:
using namespace std;
void myfunc(string foo)

This will complain now that it should have been

Re: 1.5.5 and Fortran

Hi,

> I try to use doxygen 1.5.5 (svn 612 ) with my fortran project.
> Unfortunately I get the following error
>
> Preprocessing C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
> Parsing file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
> parse error in end
> <scopename>********************************************************************
>  Error in file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90 line: 185,
> state: 4
I tried SVN version several days ago and it did not work for me
either. Unfortunately, I do not have time to look into it.

I think I'll have some time next week to fix this and look through
some issues in bugzilla.

Oleg

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: 1.5.5 and Fortran

> Hi,
> 
>> I try to use doxygen 1.5.5 (svn 612 ) with my fortran project.
>> Unfortunately I get the following error
>>
>> Preprocessing C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
>> Parsing file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90...
>> parse error in end
>> <scopename>********************************************************************
>> Error in file C:/Users/Alin M Elena/tdtbuj/source/Constants.f90 line: 185,
>> state: 4
> I tried SVN version several days ago and it did not work for me
> either. Unfortunately, I do not have time to look into it.
> 
> I think I'll have some time next week to fix this and look through
> some issues in bugzilla.
> 
> Oleg

Hi Oleg and the others,
	I gave a try to the new version and I also got the same error with 
fortran, after some debugging I noticed that the problem is that 
constructs like ENDIF or READ(unit,END=20) are treated like END MODULE 
or END SUBROUTINE and so on; the following changes in fortranscanner.l 
RE's work for me:

<InterfaceBody>"end"({BS_}"interface")?.*
changed to
<InterfaceBody>^{BS}"end"({BS_}"interface".*)?

Patch to suppress QFile warning when documenting VHDL

Greetings,
Here is a small patch against the current Doxygen SVN head to suppress 
QFile warnings when parsing VHDL files.

Index: vhdlscanner.l
===================================================================
--- vhdlscanner.l       (revision 613)
+++ vhdlscanner.l       (working copy)
 <at>  <at>  -1668,6 +1668,7  <at>  <at> 
   current=0;

   groupLeaveFile(yyFileName,yyLineNr);
+  inputFile.close();

   //mergeBrief(current_root);
   //mergeGrouping(current_root,0)

Regards,
Keith

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

\li2, \li3 revisited (was: Help With Aliases Command)

(thread: http://thread.gmane.org/gmane.text.doxygen.general/6586)

Jake Colman wrote:
> Matthew Woehlke writes:
>> Should I try to dust off my patch for these?
> 
> I certainly think that you should.  I just submitted a patch for ti
> support "\default" as a new command that behaves like "\param". I hope
> that Dimitri accepts it since I believe that a "Defaults" section would
> be very useful.  I also think that a generic solution using "\li2[3]"
> would be useful as well.

This seems to be the patch I have lying around. Trying to reconstruct 
this from the 20k (most of that auto-generated BS, granted) of diff I 
have vs. the base 1.4.7 sources would be... interesting, so hopefully 
this works. No guesses how well it will apply against current svn, though.

Dmitri, can we revisit this? I'm happy to see about getting it cleaned 
up against current svn if you'd be willing to accept it.

--

-- 
Matthew
EPUN: program terminated due to egregious wordplay

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: \li2, \li3 revisited (was: Help With Aliases Command)

On 21 feb 2008, at 23:45, Matthew Woehlke wrote:

> (thread: http://thread.gmane.org/gmane.text.doxygen.general/6586)
>
> Jake Colman wrote:
>> Matthew Woehlke writes:
>>> Should I try to dust off my patch for these?
>>
>> I certainly think that you should.  I just submitted a patch for ti
>> support "\default" as a new command that behaves like "\param". I  
>> hope
>> that Dimitri accepts it since I believe that a "Defaults" section  
>> would
>> be very useful.  I also think that a generic solution using "\li2[3]"
>> would be useful as well.
>
> This seems to be the patch I have lying around. Trying to reconstruct
> this from the 20k (most of that auto-generated BS, granted) of diff I
> have vs. the base 1.4.7 sources would be... interesting, so hopefully
> this works. No guesses how well it will apply against current svn,  
> though.
>
> Dmitri, can we revisit this? I'm happy to see about getting it cleaned
> up against current svn if you'd be willing to accept it.

Yes, I'm interested in a patch for this if it provides a solution to  
make
\param like commands.

New Release is Online Moritz 1.0.03

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Doxygen-develop mailing list
Doxygen-develop <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/doxygen-develop