doxygen-develop — List for discussing new features, submitting patches, etc.

[Doxygen-develop] Portuguese translation updated

[Rui L. <rui...@ya...>]

Hi!

In the attchement is the updated Portuguese
translation updated to the last doxygen...


Byes,

=====
Rui Lopes
www.rgl.f2s.com

__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

[Doxygen-develop] Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Dean P. <po...@ds...>]

<snip>

Let me add a big ditto to most of this.  Doxygen is great, but I find it =

is almost, but not quite there for documenting C code.

>2) * hide Macro definitions body. ( and document them like functions )

You can hide macro body with @hideinitializer.  It would be good to be ab=
le to add =

information about the type of macro parameters and expected returns where=
 =

relevant.  Also it would be nice to be able to abstract the fact that a =

macro is a macro and not a function, as sometimes you want to switch =

between functions and macros.

I also tend to want to give the full definition of a struct when =

documenting it instead of the current approach that just lists out the =

members.

I also really want to be able to generate a single HTML/man page per func=
tion =

with a big alphabetic index.  Haven't been able to find a good way to do =

this.
-- =

Dean Povey,              |em: dp...@we...|  JCSI: Java security =
toolkit
Senior S/W Developer     |ph:  +61 7 3864 5120    | uPKI: Embedded/C PKI =
toolkit
Wedgetail Communications |fax: +61 7 3864 1282    |       uASN.1: ASN.1 C=
ompiler
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Sig=
natures =

[Doxygen-develop] Re: [Doxygen-users] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Carlo W. <ca...@al...>]

On Tue, Nov 20, 2001 at 04:37:37AM +0100, Toni Moreno Giménez wrote:
> 3) (Disable File List Section)
> 
> If you are documenting a like "Object Oriented C code" is common use a couple 
> of source code files for each "object." 
> 
> myobject.c
> myobject.h 
> 
> But the final library usually have and unique header to include.
> By example mi lib has while developing the first release aprox 25 headers
> 
> but only one is needed to use the lib.

Same thing here, at least I should be able to hide heaader files
that I explicitely NOT documented (didn't add a \file in).
Doxygen now generates this page:

Here is a list of all documented files with brief descriptions:
libcw/bfd.h [code]
libcw/buf2str.h [code]			Definition of utility class buf2str
libcw/char2str.h [code]			Definition of utility class char2str
libcw/class_alloc.h [code]
libcw/class_channel.h [code]
libcw/class_channel_set.h [code]
libcw/class_continued_channel.h [code]
libcw/class_debug.h [code]
libcw/class_debug_string.h [code]
libcw/class_fatal_channel.h [code]
libcw/class_location.h [code]
libcw/class_marker.h [code]
libcw/control_flag.h [code]
libcw/core_dump.h [code]
libcw/cwprint.h [code]			Definition of the utilities cwprint and cwprint_using
libcw/debug.h [code]			This is the main header file of libcwd
libcw/debug_config.h [code]
libcw/debugmalloc.h [code]
libcw/demangle.h [code]
libcw/enum_memblk_types.h [code]
libcw/lockable_auto_ptr.h [code]
libcw/macro_ForAllDebugChannels.h [code]
libcw/macro_ForAllDebugObjects.h [code]
libcw/macro_Libcwd_macros.h [code]
libcw/max_label_len.h [code]
libcw/pc_mangled_function_name.h [code]
libcw/private_allocator.h [code]
libcw/private_assert.h [code]
libcw/private_debug_stack.h [code]
libcw/private_internal_string.h [code]
libcw/private_internal_stringstream.h [code]
libcw/private_internal_vector.h [code]
libcw/private_set_alloc_checking.h [code]
libcw/private_threading.h [code]
libcw/private_TSD.h [code]
libcw/strerrno.h [code]
libcw/sysd.h [code]
libcw/type_info.h [code]

while I only want the four documented ones to appear.
The user NEVER has to #include any other.

-- 
Carlo Wood <ca...@al...>

[Doxygen-develop] Making an Easy and fast readable C Library Manual reference.(TODO-Suggestions)

[Toni M. <ton...@wa...>]

Well , First we should define what is "easy" and "fast readable" Manual.
I'm now using doxigen for my C Library , and I want to achieve a Referenc=
e=20
manual  that looks like  GLib and Gtk+  API reference Manual(=20
http://www.gtk.org/api/ )

I was been  testing diferent doxigen features, and I think it is really=20
posible to do a nice API doc like Glib uses ( for C users)

But I have detected some leaks in current features, in order  to do a per=
fect=20
API C reference manual.

------------------------------------------

1) * hide Enum Values.

2) * hide Macro definitions body. ( and document them like functions )


3) (Disable File List Section)

If you are documenting a like "Object Oriented C code" is common use a co=
uple=20
of source code files for each "object."=20

myobject.c
myobject.h=20

But the final library usually have and unique header to include.
By example mi lib has while developing the first release aprox 25 headers

but only one is needed to use the lib.

#include <mylibheader.h>

and mylibheader.h  contains the actual header files.

#include <object1.h>
#include <object2.h>
.....
#include <object3.h>

I want to say that I don't need a "File List" Section in the HTML Output =
 ,=20
and I can't disable it  now.

4)  Add an arbitrary header file per group

Something like..

/** @addgroup myobject=20
*	@mygroupheader  mylibheader.h <<------=20
*	@{
*/

Well I'm making "Object" documentation one per group
and the grouping feature runs OK. but  I can't specify what's header's fi=
le=20
needs this group.

--------------------------------------

There are some other little things that can be added , but the most impor=
tat=20
are the before explained. ( 1 and 2 for both ,C and C++ API reference man=
uals)

About other features, ALL are running OK and the feel and look of my manu=
al=20
is olmost the same as GLib and Gtk manuals. ( only changing colors of=20
course..).

I can search for some other features , If any developer ask me.

Lots of Thanks.

--=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Toni Moreno Gim=E9nez
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Pje de las rosas  n=BA 22
Vilassar de Mar=20
(Barcelona) Espa=F1a
CP: 08340
-----------------
Tel:937598149
Tel: 699706656
-----------------

[Doxygen-develop] Building Doxygen under Cygwin

[Stephen G. <ste...@el...>]

I have found that Doxygen will work well under Cygwin nowadays. Up until
last week it only needed one small edit:

In qtools/qglobal.h, line 99 onwards, changed:

#elif defined(linux) || defined(__linux) || defined(__linux__)
#define _OS_LINUX_
#elif defined(__FreeBSD__)
#define _OS_FREEBSD_

to

#elif defined(linux) || defined(__linux) || defined(__linux__)
#define _OS_LINUX_
#elif defined(__CYGWIN__)
#define _OS_CYGWIN_
#elif defined(__FreeBSD__)
#define _OS_FREEBSD_

Ie, added in a "do-nothing" for Cygwin, simply to disable the #error at
the end of the long list.

After that, because Cygwin isn't in the PLATFORMS file, ran ./configure
with -platform linux-g++ : clean compile, which has worked without any
apparent problems for the last few weeks.

The change that broke this: I just updated from CVS this afternoon and
received a compilation error at line 200 of language.cpp, which reads:

    theTranslator=new TranslatorRomanian;

I can not pinpoint the problem yet (no time) but adding -english-only to
the ./configure makes everything compile...

Regards,
Stephen Goudge

[Doxygen-develop] French translation updated

[Xavier O. <xav...@an...>]

Hi, 

Here's the new translator_fr.h (in attachment).
-trReferences() added // new since 1.2.11

Greetings,

Xavier.
--
 D2SET Scientific and Technical Non profit Association
  http://www.d2set.org/
  mailto:d2...@d2...

 Artificial Anthill Project
  http://www.aanthill.org/
  mailto:aan...@aa...

[Doxygen-develop] Re: Comments... (was RE: [Doxygen-users] Multiple comments -combining )

[Dimitri v. H. <di...@st...>]

On Fri, Nov 16, 2001 at 08:28:10AM +0100, Prikryl,Petr wrote:
> (Sent to the developers list; the copy sent to doxygen users list -- please
> reply in developers)
> 
> Hi doxygeners,
> 
> It seems that comments in doxygen are discussed more often
> now.  Looking at doxygen architecture documentation 
> (doxygen/html/arch.html), is there some clear separation 
> between the comment parsing and the language construct
> parsing?

The separation is currently not as clean as it should be.
The language parser also contains pass one of the documentation
block parsing. Pass two is already moved to doc.l. 

> 
> I think that the separation of the two parsers should be done
> before any important changes to comment parsing.  

I agree. I have this on my todo list for quite some time.
I am also trying to capture the documentation constructs in
some kind of formal grammar, but so far that isn't very 
successful :-(

> Why I think so?  It would simplify the comment parsing
> enhancements, and it would add flexibility of doxygen design.
> 
> The language parser would only recognize some blocks
> of the language dependent comments as doxygen comments.
> It will implement recognition of various flavours of doxygen
> comments.  Its result will be the unified form of a doxygen
> comment without language dependent syntactic things plus
> some context information.  In other words, the language
> parser will convert Qt style, JavaDoc style, block comments,
> one-line comments, and whatever future style into one form
> that will be passed to the comment parser.
> 
> If the language and comment parsers were separated, it 
> would be much easier, for example, to process also in-body
> comments (that some people asked for).

Yes that is true, but combining comment blocks in a sensible 
and consistent way would still be equally difficult.

> The comment parser then can be programming language 
> indepedent.  This would allow implementing parsing for 
> other programming languages.  But also, this would simplify
> comment-enhancement development.  In the extreme case,
> there could be a possibility to create external comment parsers
> that would use different comment syntax.

In the end that's what I'm aiming for, but for now I concentrate
on the XML generator & parser. The problem with plugin parsers
it that what they produce needs to be understood by the next
stage.

> 
> Well crafted mechanism that will solve the requested
> "multiple comment combining" could be used also for
> in-body comments.

Good ideas on this are welcome. I still like the
idea proposed by someone to combine all comments in a body under
a section "Implementation details".

Regards,
  Dimitri

[Doxygen-develop] Comments... (was RE: [Doxygen-users] Multiple comments -combining )

[Prikryl,Petr <PRI...@sk...>]

(Sent to the developers list; the copy sent to doxygen users list -- please
reply in developers)

Hi doxygeners,

It seems that comments in doxygen are discussed more often
now.  Looking at doxygen architecture documentation 
(doxygen/html/arch.html), is there some clear separation 
between the comment parsing and the language construct
parsing?

I think that the separation of the two parsers should be done
before any important changes to comment parsing.  

Why I think so?  It would simplify the comment parsing
enhancements, and it would add flexibility of doxygen design.

The language parser would only recognize some blocks
of the language dependent comments as doxygen comments.
It will implement recognition of various flavours of doxygen
comments.  Its result will be the unified form of a doxygen
comment without language dependent syntactic things plus
some context information.  In other words, the language
parser will convert Qt style, JavaDoc style, block comments,
one-line comments, and whatever future style into one form
that will be passed to the comment parser.

If the language and comment parsers were separated, it 
would be much easier, for example, to process also in-body
comments (that some people asked for).

The comment parser then can be programming language 
indepedent.  This would allow implementing parsing for 
other programming languages.  But also, this would simplify
comment-enhancement development.  In the extreme case,
there could be a possibility to create external comment parsers
that would use different comment syntax.

Well crafted mechanism that will solve the requested
"multiple comment combining" could be used also for
in-body comments.

What is your opinion?

  Petr

-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

> -----Original Message-----
> From:	Stephen Goudge [SMTP:ste...@el...]
> Sent:	Thursday, November 15, 2001 9:13 AM
> To:	dox...@li...
> Subject:	RE: [Doxygen-users] Multiple comments -combining
> 
> The simple combining of comments is a feature that I'd certainly use.
> 
> As others (eg, Victor Wagner) do, we generate two lots of documentation
> from the sources for one library - one set from the public headers,
> detailing the API and examples for users, one with all the
> implementation detail for maintainers.
[...]

[Doxygen-develop] A little Windows support.

[Erik Z. <ze...@ma...>]

Added EOL translation to the config file output.

Erik

*******************************************
Dr. Erik Zeek
Postdoctoral Fellow
School of Physics
Georgia Institute of Technology
Atlanta, GA  30332-0430

Tel: 404-385-1034
FAX: 425-988-9013

Web:   http://www.physics.gatech.edu/frog/
Email: mailto:ze...@ma...

[Doxygen-develop] Croatian translation update

[Boris B. <bor...@zg...>]

Hi, 

Here's new translator_hr.h (in attachment).
-trReferences() added 
-better output for C sources documentation

Boris

[Doxygen-develop] Documenting the psuedo-flow of functions with Doxygen?

[John O. <joh...@er...>]

> void doSomething():
>   * Do this and that
>   * Do something

That sounds like a very intersting idea if you also coupled that to
references to other functions, i.e. you could get a (high-level) flow
involving several functions.

For instance:

void doSomething():
  * Do this
  * if foo is 10 then
    # call doSomethingElse()
    else
    # cal doSomethingCompletelyDifferent()
    endif
  * Do that

It would also be nice to be able to control level of detail in a
separate flow, in the above example, perhaps parts of doSomething() and
doSomethingCompletelyDifferent() could be shown in the same flow.

Just my crazy ideas. :)


/John

-- 
LM/ERA/RJZ/GKT John Olsson  mailto:Joh...@er...
   Ericsson Radio Systems AB, Box 1248, S-581 12 Linkoping
-------------------------------------------------------------
  Phone: +46 13 321070   ECN: 868 1070   Fax: +46 13 287370
-------------------------------------------------------------
I was doing object-oriented assembly when I was 1 year old...  
For some reason my mom insists on calling it "Playing with blocks"

[Doxygen-develop] (Wishlist) Carrying on inherited documented members to child classes

[<cy...@so...>]

Hi folks,

  This is a request for YACO(tm) (and before I swamp the list for requests,
please let me first state that I really love this tool !)

when INHERIT_DOCS=YES, a member function which reimplements a documented
base class method also inherits from the documentation. Unfortunately, when
writing classes in the following style:

    //! A useful base class
    class Base {
    public:
        //...

        //! Do something
        rettype method(argtype arg0, ...);
    private:
       virtual rettype doMethod(argtype arg0, ...) = 0;
    };
    inline rettype Base::method(arg0, ... ) { return doMethod(arg0, ...); }

    //! A specialisation of base class Base
    class Derived : public Base {
       // ...
    private:
       rettype doMethod(argtype arg0, ...); // long implementation in
Derived.cpp
    };

(this style being used to de-couple the usage interface (public) from the
customisation interface (private pure virtual functions)), there is now a
problem, when viewing the documentation of Derived: unless the private
doMethod method is documented in Base or in Derived, there is no
documentation. Besides, one has to go back to class Base to see the list of
documented, usable (public) methods !

It would be excellent if an option, like SHOW_INHERITED_PUBLIC_METHODS
appeared. With that option turned on, any documented public method inherited
from Base, but /not/ reimplemented in Derived would still appear in the
documentation of Derived (with the appropriate tag, of course).

This is probably trivial to implement, given that the "list all members"
link already has that capability (but doesn't show the list). What I'm
after, basically, is a blend between that "list all members" page (limited
to public members), and the main page (full documentation of members), all
that in the main page.

What do you think of that ? If time is a problem, I'd be willing to
implement this, if gently shown where to patch (OTOH, it may very well take
Dimitry or other core hackers a mere 5 minutes to make that new option a
reality...)

    -- Cyrille

[Doxygen-develop] Documenting the psuedo-flow of functions with Doxygen?

[Mike A. <mik...@ya...>]

Doxygen is great for documenting classes, functions,
hierarchies, etc.  But I'm wondering if there is a way
to document the comments before each statement inside
the body of a function to produce a psuedo-flow of
operation.  For example:

void doSomething() {
 /// Do this and that
     string str = "test";
     str += path;
 /// Do something
     x += 1;
     if( x >= 10) x = 0;
}

and the output would be:

void doSomething():
  * Do this and that
  * Do something

I would find it usefull to create internal
documentation on a higher level.

Thanks!
Mike

__________________________________________________
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com

[Doxygen-develop] Re: Config file: Drive specification redundancy (patch)

[Johan E. <Joh...@ua...>]

Johan Eriksson wrote:
> 
> Hi,
>    I am posting a patch that makes it unnecessary for some of the config
> parameters to specify the drive specification. This can be achieved by
> using a relative path but I find it much clearer and sometimes simplier
> to use the absolute path. It is assumed however, that the drive will be
> the same as where the config file (Doxyfile) is located.
> 
This part of the patch was apperently totally unnecessary since it
actually is
workning without specify the drive letter. Besides the patch is also
faulty since
it didn't handle relative paths.....so I've removed this from the patch.
I am sorry if this has caused any inconvenience for you.  
 
> Use case:
snip....

> Before:  INPUT_FILTER = J:/FolderName1/FolderName2/Filter

Note: The after: is working without the patch....
> After:   INPUT_FILTER = /FolderName1/FolderName2/Filter
> 
snip....

> Included in this patch there is also possible the leave the INPUT tag
> empty, in that case the location of the current Doxyfile is used as
> input directory.
This is the only thing left in the attached patch.......
> 
> Example of config file parameter:
> 
> Before:  INPUT = J:/FolderName1/FolderName2
> After:   INPUT =
> 
> /Johan
>

[Doxygen-develop] Doxygen: CZ update + something more...

[Prikryl,Petr <PRI...@sk...>]

Hi Dimitri and others,

I have noticed that the idea of TranslatorAdapterCVS was somehow
redundant.  It is much clearer to use TranslatorAdapter_x_y_z directly even
for the CVS releases.  Because of that, I did simplify the
translator_adapter.h
by renaming TranslatorAdapterCVS to TranslatorAdapterBase and made
it the abstract class.  Consequently, I did simplify the translator.pl
script so
that there is nothing like "almost up-to-date" translator (only the
up-to-date
or obsolete).  I have also updated the language.tpl documentation with 
respect to that.

Finally, the archive contains also the updated translator_cz.h.

 <<doxup.zip>> 

Best Regards,
  Petr

-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

Re: [Doxygen-develop] How to get the first line of a definition?

[Dimitri v. H. <di...@st...>]

On Mon, Oct 29, 2001 at 12:46:20PM +0100, Jean-Philippe Orsini wrote:
> Hi,
> 
> 	I would like to know if there is a way to get the position of 
> the first line of a C++ definition in header files.
> 
> For example if a .h contains:
> 0: void foo(int a,
> 1:          int b,
> 2:          int c) {
> 3:     // code...
> 4: }
> 
> Definition::getDefLine() will return the position of the last line of the 
> definition (2).
> 
> Definition::getStartBodyLine() and Definition::getEndBodyLine() will 
> return the position of the body ( 2, 4).
> 

There is no way to get that information at the moment. Doxygen's parser
only sees that something is a function definition when the opening { is 
read and does not remember where the function definition has started. 
This would require some extra administration in scanner.l (this could 
probably be added to addType()).

Regards,
  Dimitri

Re: [Doxygen-develop] Adding a new [programming] language

[Dimitri v. H. <di...@st...>]

On Mon, Oct 29, 2001 at 05:35:14PM +0530, Biswapesh Chattopadhyay wrote:
> Hi
> 
> How does one go about adding support for a new programming language in
> Doxygen ? I would like to use Doxygen to generate docs from PL/SQL code.

There is no easy way to do this at the moment. You could look at 
src/scanner.l and src/entry.h. The idea is that a tree of Entry objects
is produced (Entries could be variables, functions, classes, documentation
blocks, etc), which are then further processed by doxygen. Maybe you can 
write something similar for PL/SQL code. 

Regards,
  Dimitri

[Doxygen-develop] Changes to add an EXAMPLE_RECURSIVE configuration tag

[Stephen G. <ste...@el...>]

Hello,

I've added a new configuration tag to my local copy of Doxygen (attached
are the results of running "cvs diff -u" against the two modified files,
doxygen.cpp and config.l, against the CVS version as of 15:30 GMT
Thursday November 1st).

With these changes in place, if you set EXAMPLE_RECURSIVE to YES and
RECURSIVE to NO then files used for examples, using \dontinclude and
\include, will recursively search from EXAMPLE_PATH without also
allowing the INPUT directories to be recursively scanned. Set
EXAMPLE_RECURSIVE to NO (the default) and nothing has changed.

This change makes \dontinclude and \include usable with the way that I
have the source code for libraries arranged:

  projects/lib1/-+-m/
                 |
                 +-dox/

where projects/lib1/ contains all the *.h files required to _use_ the
library (the interface) and projects/lib1/m/ contains the implementation
of the library (all the *.cpp etc and a number of *.h that contain
implementation details and some more files of Doxygen comments).
projects/lib1/dox/ contains files with Doxygen comments for all the long
items that should not go into normal source modules, such as as
dissections of examples that illustrate how to use the library (using
\include etc), which I happen to put into files ending in ".dox".

There is a separate examples directory tree:

  projects/examples/-+-lib1/-+-eg1/main.cpp
                     |       |
                     |       +-eg2/main.cpp stuff.cpp thing.cpp
                     |
                     +-/lib2/eg1

etc.

BTW there are very real reasons for this structure - well, the _real_
structure, which
is even more complicated than the above - but that will suffice :-)

I generate two lots of Doxygen output, one for people who want to use
the library and one for those who want to know the implementation
details; the main difference between the Doxygen configuration files are
that the user-level one has

@INCLUDE               = common-config.doxy
INPUT                  = . ./dox
FILE_PATTERNS          = *.h *.dox
RECURSIVE              = NO
EXAMPLE_RECURSIVE      = YES

whilst the implementation one has

@INCLUDE               = common-config.doxy
INPUT                  = .
FILE_PATTERNS          = *.h *.dox *.cpp
RECURSIVE              = YES

Within lib1/dox/ there are dissections of the the examples, eg1 and eg2,
which start with:

 \dontinclude lib1/eg1/main.cpp

and

 \dontinclude lib1/eg2/main.cpp

Without the new EXAMPLE_RECURSIVE tag, this arrangement would always
work for the implementation documentation, but for the user
documentation, with RECURSIVE=NO, the examples would not be found or, if
one set RECURSIVE=YES, the examples _would_ be found but (some of) the
details of the implementation would also be dragged in.


I hope this is of interest,
Regards,
Stephen Goudge

[Doxygen-develop] patches for slovene language (latex)

[Mitja U. <mit...@zr...>]

Hello!

The following patches are for generating latex files which uses Latin-2
encoding.

Mitja

[Doxygen-develop] DocBook/XML

[Hunter M. <hma...@vi...>]

I mis-addressed this before. I wanted to see if this was of use to
anyone on doxygen-develop.

Thanks for any help ro comments.

	hunter

[Doxygen-develop] Adding a new [programming] language

[Biswapesh C. <bis...@tc...>]

Hi

How does one go about adding support for a new programming language in
Doxygen ? I would like to use Doxygen to generate docs from PL/SQL code.

Thanks in advance
- Biswa.

[Doxygen-develop] How to get the first line of a definition?

[Jean-Philippe O. <jpo...@il...>]

Hi,

	I would like to know if there is a way to get the position of 
the first line of a C++ definition in header files.

For example if a .h contains:
0: void foo(int a,
1:          int b,
2:          int c) {
3:     // code...
4: }

Definition::getDefLine() will return the position of the last line of the 
definition (2).

Definition::getStartBodyLine() and Definition::getEndBodyLine() will 
return the position of the body ( 2, 4).

Regards,
				JeanFI.

[Doxygen-develop] class gets lost

[Berno L. <ber...@ep...>]

Hello,

the following java-example seems to be ignored by doxygen:

package mypackage;
public class MyClass {
	public String html =3D "\"/*";
}

If you initialize the string with something other (e.g. delete the "*" or=
 the=20
'"'), doxygen works correctly.

Wasn't easy the track that down in a SRC with lots of inner classes and=20
regular expressions :-)

I couldn't reproduce that with a cpp file like the following, so it seems=
 to=20
be java specific.

class MyClass
{
 public:
	char* getHtml();
};

char *MyClass::getHtml()
{
	char *html =3D "\"/*";
	return html;
}

int main( int argc, char* argv[] )
{
	return 0;
}

---
Gru=DF

Berno

[Doxygen-develop] class gets lost

[Berno L. <ber...@ep...>]

Hello,

the following java-example seems to be ignored by doxygen:

package mypackage;
public class MyClass {
	public String html =3D "\"/*";
}

If you initialize the string with something other (e.g. delete the "*" or=
 the=20
'"'), doxygen works correctly.

Wasn't easy the track that down in a SRC with lots of inner classes and=20
regular expressions :-)

I couldn't reproduce that with a cpp file like the following, so it seems=
 to=20
be java specific.

class MyClass
{
 public:
	char* getHtml();
};

char *MyClass::getHtml()
{
	char *html =3D "\"/*";
	return html;
}

int main( int argc, char* argv[] )
{
	return 0;
}

---
Gru=DF

Berno

[Doxygen-develop] Config file: Drive specification redundancy (patch)

[Johan E. <Joh...@ua...>]

Hi,
   I am posting a patch that makes it unnecessary for some of the config
parameters to specify the drive specification. This can be achieved by
using a relative path but I find it much clearer and sometimes simplier
to use the absolute path. It is assumed however, that the drive will be
the same as where the config file (Doxyfile) is located.

Use case:

If you are using a Windows client to generate the documentation, it is
not neccessary to know the specific drive that you have to use in order
to connect the server where the all the source code are located.

Example of config file parameter:

Before:  INPUT_FILTER = J:/FolderName1/FolderName2/Filter
After:   INPUT_FILTER = /FolderName1/FolderName2/Filter

This assumes that the Doxyfile is located somewhere on drive J.

The patch handles the following parameters:
OUTPUT_DIRECTORY, INPUT_FILTER and HTML_FOOTER

Included in this patch there is also possible the leave the INPUT tag
empty, in that case the location of the current Doxyfile is used as
input directory.

Example of config file parameter:

Before:  INPUT = J:/FolderName1/FolderName2
After:   INPUT =

/Johan

PS Dimitri, if all parameters should be covered, a better solution than
the current patch should probably be done, something like the
substEnvVars() implementation. So, if you feel that this could be
something for the general doxygen, I would be happy to write a code
proposal DS