doxygen-users — List for users of doxygen

[Doxygen-users] There seems to be truncated summary tag markup in the output. Is this a bug?

[mkamoski <mka...@gm...>]

There seems to be truncated summary tag markup in the output. Is this a bug?

See the example below.

example_begin

class   AttachmentRow 

  Represents strongly named DataRow class. /summary> More...
 
  
class   AttachmentRowChangeEvent 

  Row event argument class /summary> More... 

example_end

Please advise.

Thanks.

-- Mark Kamoski




--
Sent from: http://doxygen.10944.n7.nabble.com/Doxygen-Users-f3.html

[Doxygen-users] How to avoid the warning "Internet Explorer restricted this webpage from running scripts or ActiveX controls" for output?

[mkamoski <mka...@gm...>]

How to avoid the warning "Internet Explorer restricted this webpage from
running scripts or ActiveX controls" for output?



--
Sent from: http://doxygen.10944.n7.nabble.com/Doxygen-Users-f3.html

[Doxygen-users] Issue with Doxygen and LaTex pdf generation when using grouping and params

[Joonas G. <joo...@ka...>]

Hey,

I'm having this issue with Doxygen + MikTex (or any tex) that when using grouping and param-tags I get only generic error about ! missing } inserted.

If you take a source file like this:

'''
/**
 *  @defgroup Example examplegroup
 *  @{ */

/**
 *  @brief Example function
 *  @param[in] e example var */
void exampleFunction( int e )
{
        (void)e;
}

/** @} */
'''

and try to run doxygen and after that latex/make.bat (or pdflatex refman) I get this error:

'''
(group___example.tex ("C:\Program Files\MiKTeX 2.9\tex/latex/psnfss\ts1phv.fd")
("C:\Program Files\MiKTeX 2.9\tex/latex/psnfss\t1pcr.fd")
! Missing } inserted.
<inserted text>
                }
l.28 \end{DoxyParams}
'''

I think the issue is related to grouping and doxygen.sty DoxyParam section ifthen-begins that aren't correctly closed? But as a Doxygen / LaTex noob that is just a non-educated guess. But is this a bug or is there something I can do about this? Any workarounds?

There is also StackOverFlow question about this in https://stackoverflow.com/questions/54780072/doxygen-latex-cannot-create-pdf-when-using-param-tags . I try to update that page if I find something new. But help would be very much appreciated.

Yours, sincerely

    - Joonas Greis
    @ joo...@ka...
    > kamilla @ QuakeNet | IRCnet | freenode
    ☎ +358 414 984 293

[Doxygen-users] Confused about behaviour of TOC_INCLUDE_HEADINGS

[Jakob v. B. <jak...@gm...>]

Dear all,

Today I tried setting a value >0 for TOC_INCLUDE_HEADINGS. This caused
headers to get added to the TOC, as expected, but the headers themselves
simultaneously disappeared from the output! The latter was quite unexpected
to me.

Is this the expected behaviour?

Sincerely, Jakob

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

> Short of actually implementing complex incremental builds, there's
> another, unrelated and also much simpler optimization Doxygen could do:
> just vaguely keep track of modified times on *input* files.
> [..]
> This would make a huge difference for incremental builds that involve not
> just doxygen but other (and faster) tools too; they could just skip running
> doxygen when not needed.
>
> PS: If anyone has ideas on how to emulate this with a small number of
> lines of CMake then please share. For instance this could generate an empty
> file right before starting doxygen as a decent approximation.
>
>
OK, emulating this in CMake was much easier than I thought. It would still
be simpler and safer if Doxygen provided it for any build system...

set(DOXYGEN_RUN_STAMP build/doxygen_run_tstamp)

# Duplicates Doxyfile, must be kept in sync manually
file(GLOB_RECURSE .  DOXYGEN_SOURCES
../include/*.[c,h]
../tests/*.[c,h]
 ...
)

add_custom_command(
   OUTPUT ${DOXYGEN_RUN_STAMP}
   COMMAND cmake -E touch ${DOXYGEN_RUN_STAMP}
   COMMAND doxygen ...
   ...
   DEPENDS ${DOXYGEN_SOURCES}
)

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

Short of actually implementing complex incremental builds, there's another,
unrelated and also much simpler optimization Doxygen could do: just vaguely
keep track of modified times on *input* files.

1. Offer some way to --remember the newest modified_time across all input
files. Could be stored in some empty file.
2. Then have a new, optional feature that: "--runs only if any input file
is newer than this (empty) file"

This would make a huge difference for incremental builds that involve not
just doxygen but other (and faster) tools too; they could just skip running
doxygen when not needed.

I considered filing a new doxygen feature request for this on github (and
also for the previously discussed *output* mtime optimization), however
https://github.com/doxygen/doxygen/issues has 1800+ open issues right now
so it feels like a black hole.

PS: If anyone has ideas on how to emulate this with a small number of lines
of CMake then please share. For instance this could generate an empty file
right before starting doxygen as a decent approximation.

[Doxygen-users] Setting visible=no seems not to work

[Jakob v. B. <jak...@gm...>]

Dear all,

Allthough I have been using Doxygen on occasion, this is the very first
time I try to fine-tune the output using a layout file.

In particular I'm trying to set the visible attribute of the
file->memberdef->defines tag to 'no' as a way to prevent generation of a
'Macro Definition Documentation' section on the file documentation page of
a C source file.

But that section appears, whether I set visible="no" or visible="0" or
visible="NO". I'm sure the layout file is used, because if I change the
'title' attribute to some made up value, that value nicely appears instead
of the 'Macro Definition Documentation' title.

Am I misunderstanding something? Or did I hit some strange bug?

Sincerely,
Jakob

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

Le ven. 8 févr. 2019 à 13:08, Travis Everett <tra...@gm...> a
écrit :

> This doesn't address the portability issue, but I'm not sure I see why you
> would need to copy timestamps in two directions?
>
> I'm just suggesting that you use Doxygen to generate a "scratch" copy that
> you never deploy (and could delete immediately after rsyncing) and using a
> one-way rsync to another location where you store the "real" copy for
> use/deployment/processing/etc. Sphinx would run on the "real" copy, not the
> scratch one.
>

Thanks Travis, I think you're right.

I went for a "two-ways" solution because it cost little more code once I
opted to sort of "re-implement rsync in Python" instead of using rsync
itself. It also saved me changing the doxygen destination which was a bit
more convenient for testing and comparing. Then I lost track of this
non-requirement :-)

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Travis E. <tra...@gm...>]

This doesn't address the portability issue, but I'm not sure I see why you
would need to copy timestamps in two directions?

I'm just suggesting that you use Doxygen to generate a "scratch" copy that
you never deploy (and could delete immediately after rsyncing) and using a
one-way rsync to another location where you store the "real" copy for
use/deployment/processing/etc. Sphinx would run on the "real" copy, not the
scratch one.

To illustrate, I wrote two quick files, rsynced them, waited a minute,
appended to one file, rewrote one file with the same data, added a third
file, and then rsynced again.

$ echo "test1" > scratch/a
$ echo "test2" > scratch/b
$ rsync -rc scratch/ deploy/
# wait a minute
$ echo "test3" >> scratch/a
$ echo "test2" > scratch/b
$ echo "test3" > scratch/c
$ rsync -rc scratch/ deploy/
$ ls -l scratch
...
-rw-r--r--   1 a staff  12 Feb  8 14:28 a
-rw-r--r--   1 a staff   6 Feb  8 14:28 b
-rw-r--r--   1 a staff   6 Feb  8 14:28 c

$ ls -l deploy
...
-rw-r--r--   1 a staff  12 Feb  8 14:28 a
-rw-r--r--   1 a staff   6 Feb  8 14:27 b
-rw-r--r--   1 a staff   6 Feb  8 14:28 c

Even though I modified all 3 files, rsync only copied the two with changed
*content.* The file with no changes keeps its old timestamp. When you run
Sphinx against this copy the next time, it should only process the two
files with changed timestamps.

On Fri, Feb 8, 2019 at 1:15 PM Marc Herbert <mar...@gm...> wrote:

> Le ven. 8 févr. 2019 à 09:55, Travis Everett <tra...@gm...>
> a écrit :
>
>> I wonder if you could just use rsync (without timestamp checking) for
>> this? If your:
>>
>>    - documentation set isn't so large that temporarily having a second
>>    set causes problems
>>    - configuration is such that output stays the same until your source
>>    or Doxygen versions change
>>
>> You could keep the real/stable output copy in one location, generate a
>> temporary copy into a separate location, then rsync without timestamp
>> checking (may need to use checksum mode?)
>>
>
> I'm a big fan of rsync and I considered it. In fact one of the function in
> my python script is called "rsync" :-) However I don't think it can do this
> particular timestamp restoration job, I mean not unless you invoked it once
> per file but by then you wrote as much code.
>
> Rsync can create an initial "shadow"/backup copy from the first build just
> fine. What I don't think rsync can do is take a completely different action
> depending on whether the file content has changed or not, *on a per file
> basis.* IF the file content has changed THEN copy data *and* timestamp TO
> the backup ELSE IF the file content hasn't changed THEN copy the old
> timestamp FROM the backup = in the *opposite* direction!
>
> So opposite directions means two separate rsync invocations: can you run
> these two rsync operations one after the other without one breaking the
> other? Taking into account new files showing up and obsolete files
> disappearing?
>
> Another portability issue: for some unknown reasons rsync seems also to be
> an undesired dependency for many Windows users, robocopy seems more
> popular. Maybe robocopy supports some NTFS features better?
>
> Cheers,
>
> Marc
>
>

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

Le ven. 8 févr. 2019 à 09:55, Travis Everett <tra...@gm...> a
écrit :

> I wonder if you could just use rsync (without timestamp checking) for
> this? If your:
>
>    - documentation set isn't so large that temporarily having a second
>    set causes problems
>    - configuration is such that output stays the same until your source
>    or Doxygen versions change
>
> You could keep the real/stable output copy in one location, generate a
> temporary copy into a separate location, then rsync without timestamp
> checking (may need to use checksum mode?)
>

I'm a big fan of rsync and I considered it. In fact one of the function in
my python script is called "rsync" :-) However I don't think it can do this
particular timestamp restoration job, I mean not unless you invoked it once
per file but by then you wrote as much code.

Rsync can create an initial "shadow"/backup copy from the first build just
fine. What I don't think rsync can do is take a completely different action
depending on whether the file content has changed or not, *on a per file
basis.* IF the file content has changed THEN copy data *and* timestamp TO
the backup ELSE IF the file content hasn't changed THEN copy the old
timestamp FROM the backup = in the *opposite* direction!

So opposite directions means two separate rsync invocations: can you run
these two rsync operations one after the other without one breaking the
other? Taking into account new files showing up and obsolete files
disappearing?

Another portability issue: for some unknown reasons rsync seems also to be
an undesired dependency for many Windows users, robocopy seems more
popular. Maybe robocopy supports some NTFS features better?

Cheers,

Marc

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Travis E. <tra...@gm...>]

I wonder if you could just use rsync (without timestamp checking) for this?
If your:

   - documentation set isn't so large that temporarily having a second set
   causes problems
   - configuration is such that output stays the same until your source or
   Doxygen versions change

You could keep the real/stable output copy in one location, generate a
temporary copy into a separate location, then rsync without timestamp
checking (may need to use checksum mode?)

It might be possible to accomplish something similar if you keep the output
in git or another vcs if they're capable of preserving timestamps, but I
haven't looked into that.

On Fri, Feb 8, 2019 at 11:22 AM Marc Herbert <mar...@gm...> wrote:

>
>> The simplest method in my mind would be  to have a post-process task
>> that compares the Doxygen output directory with another copy, updating
>> that copy if there is a ''significant' (not just timestamping)
>> difference. It would be a simple enough program to write to customize
>> for you own needs.
>>
>
> That was my plan B. I've implemented it in Python and it works:
> https://github.com/zephyrproject-rtos/zephyr/pull/13159
>  restore_modifications_times.py
> In this particular example this brings down the incremental build time
> from 70-80 seconds down to less than 10 seconds.
>
> It took a surprisingly high number of lines of code: about 100. As usual
> file management in Python proved wordy. But hey, data structures suck in
> shell script and it's not even portable anyway. To be fair these 100 lines
> include logging and a decent option parser with help text.
>
> This script is not specific to Doxygen and could be used for other similar
> situations (Apache license).
>
> Back to Doxygen I suspect this script could be entirely avoided with say
> 10-20 lines of logic inside Doxygen itself? :-(
>
> Marc
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

>
>
> The simplest method in my mind would be  to have a post-process task
> that compares the Doxygen output directory with another copy, updating
> that copy if there is a ''significant' (not just timestamping)
> difference. It would be a simple enough program to write to customize
> for you own needs.
>

That was my plan B. I've implemented it in Python and it works:
https://github.com/zephyrproject-rtos/zephyr/pull/13159
 restore_modifications_times.py
In this particular example this brings down the incremental build time from
70-80 seconds down to less than 10 seconds.

It took a surprisingly high number of lines of code: about 100. As usual
file management in Python proved wordy. But hey, data structures suck in
shell script and it's not even portable anyway. To be fair these 100 lines
include logging and a decent option parser with help text.

This script is not specific to Doxygen and could be used for other similar
situations (Apache license).

Back to Doxygen I suspect this script could be entirely avoided with say
10-20 lines of logic inside Doxygen itself? :-(

Marc

[Doxygen-users] Constraint on generic class in C#

[Deepak B. <Dee...@ev...>]

Hello,

Do you support the following C# Code

// Because of the base class constraint, all type arguments
// passed to Test must have A as a base class.
class Test<T> where T : A {
  T obj;

  public Test(T o) {
    obj = o;
  }

  public void SayHello() {
   // OK to call Hello() because it's declared
   // by the base class A.
   obj.Hello();
  }
}

Regards

Deepak Bhatia

________________________________

The information in this e-mail is the property of Evalueserve and is confidential and privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and will be unlawful. If you receive this message in error, please notify the sender immediately and delete all copies of this message.

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its *filesystem* timestamp?

[Marc H. <mar...@gm...>]

No, that's not enough because I'm referring to the modified timestamp on
the *filesystem*, not to any timestamp embedded in the code (Subject
changed accordingly)

Marc

Le mer. 6 févr. 2019 à 23:46, Sebastien Loriot (GeometryFactory) <
slo...@gm...> a écrit :

> At least for html you can set the option HTML_TIMESTAMP = OFF.
>
> On 02/07/2019 04:15 AM, Richard Damon wrote:
> > On 2/6/19 9:45 PM, Marc Herbert wrote:
> >> Hi,
> >>
> >>   I understand incremental doxygen compilation is a hard problem. I've
> >> read some of the past discussions. This request is *not* about
> >> incremental doxygen compilation and it is not about making doxygen
> >> faster at all. It's about something much simpler.
> >>
> >> Can doxygen redundantly recompute everything from scratch (even when
> >> no input has changed), and then at the very end compare and realise
> >> that it just regenerated the exact same (XML, HTML,...) output file
> >> that is already there from the previous run? Is there in this case an
> >> option /not/ to refresh the timestamp? I mean on a per output file
> >> basis of course.
> >>
> >> Refreshing the timestamp has a disastrous cascade effect on further
> >> processing like Sphinx which wrongly assumes everything has changed
> >> even when no doxygen output has changed at all (except timestamps).
> >>
> >> Marc
> > The simplest method in my mind would be  to have a post-process task
> > that compares the Doxygen output directory with another copy, updating
> > that copy if there is a ''significant' (not just timestamping)
> > difference. It would be a simple enough program to write to customize
> > for you own needs.
> >
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its timestamp?

[Sebastien L. (GeometryFactory) <slo...@gm...>]

At least for html you can set the option HTML_TIMESTAMP = OFF.

Sebastien.

On 02/07/2019 04:15 AM, Richard Damon wrote:
> On 2/6/19 9:45 PM, Marc Herbert wrote:
>> Hi,
>>
>>   I understand incremental doxygen compilation is a hard problem. I've
>> read some of the past discussions. This request is *not* about
>> incremental doxygen compilation and it is not about making doxygen
>> faster at all. It's about something much simpler.
>>
>> Can doxygen redundantly recompute everything from scratch (even when
>> no input has changed), and then at the very end compare and realise
>> that it just regenerated the exact same (XML, HTML,...) output file
>> that is already there from the previous run? Is there in this case an
>> option /not/ to refresh the timestamp? I mean on a per output file
>> basis of course.
>>
>> Refreshing the timestamp has a disastrous cascade effect on further
>> processing like Sphinx which wrongly assumes everything has changed
>> even when no doxygen output has changed at all (except timestamps).
>>
>> Marc
> The simplest method in my mind would be  to have a post-process task
> that compares the Doxygen output directory with another copy, updating
> that copy if there is a ''significant' (not just timestamping)
> difference. It would be a simple enough program to write to customize
> for you own needs.
> 

Re: [Doxygen-users] Compare with already existing and identical output file and *not* refresh its timestamp?

[Richard D. <Ri...@Da...>]

On 2/6/19 9:45 PM, Marc Herbert wrote:
> Hi,
>
>  I understand incremental doxygen compilation is a hard problem. I've
> read some of the past discussions. This request is *not* about
> incremental doxygen compilation and it is not about making doxygen
> faster at all. It's about something much simpler.
>
> Can doxygen redundantly recompute everything from scratch (even when
> no input has changed), and then at the very end compare and realise
> that it just regenerated the exact same (XML, HTML,...) output file
> that is already there from the previous run? Is there in this case an
> option /not/ to refresh the timestamp? I mean on a per output file
> basis of course.
>
> Refreshing the timestamp has a disastrous cascade effect on further
> processing like Sphinx which wrongly assumes everything has changed 
> even when no doxygen output has changed at all (except timestamps).
>
> Marc
The simplest method in my mind would be  to have a post-process task
that compares the Doxygen output directory with another copy, updating
that copy if there is a ''significant' (not just timestamping)
difference. It would be a simple enough program to write to customize
for you own needs.

-- 
Richard Damon

[Doxygen-users] Compare with already existing and identical output file and *not* refresh its timestamp?

[Marc H. <mar...@gm...>]

Hi,

 I understand incremental doxygen compilation is a hard problem. I've read
some of the past discussions. This request is *not* about incremental
doxygen compilation and it is not about making doxygen faster at all. It's
about something much simpler.

Can doxygen redundantly recompute everything from scratch (even when no
input has changed), and then at the very end compare and realise that it
just regenerated the exact same (XML, HTML,...) output file that is already
there from the previous run? Is there in this case an option *not* to
refresh the timestamp? I mean on a per output file basis of course.

Refreshing the timestamp has a disastrous cascade effect on further
processing like Sphinx which wrongly assumes everything has changed  even
when no doxygen output has changed at all (except timestamps).

Marc

Re: [Doxygen-users] difference between readthedocs generated and local

[Ryan S. E. <rel...@um...>]

Hi Travis,

Thanks for your reply!  This all sounds reasonable.  I won't be able to dig-in 
to this right away, but I'll put it on my list to get back to soon.

Thanks,

Ryan

On Thu, 31 Jan 2019, Travis Everett wrote:

> Ryan,
>
> I don't know a ton about how those parts of the codebase work so I stalled
> a bit hoping someone else would respond (there's some chance I'll mis-lead
> you here...). In any case, a good place to start is by seeing whether the
> behavior changed in 1.8.12/13/14. That should let you narrow your focus to
> just commits in a single version.
>
> If you aren't set up to build Doxygen from source (and/or aren't
> comfortable doing so), it's probably fine to open an issue report with the
> behavior you've seen, which version changed it, and a minimal set of
> files/config necessary to reproduce it. If you are comfortable building
> from source you can push this further and identify the specific commit.
>
> Hopefully the issue you're seeing was caused by an update to
> src/fortranscanner.i or src/fortrancode.i (there are probably only a few
> commits touching those per version). You can use git or github to identify
> which commits between two versions touched either of those files, and
> recompile/rebuild (depending on how long your docs take to build you may be
> able to speed this up a lot by making a separate config that just includes
> the minimum set of files you need to see the behavior) at each to see which
> introduces the break.
>
> If that doesn't work (or if there are more commits than I suspect touching
> those two files) you can use the more general git bisect command (along
> with a recompile and rebuild doc cycle) to narrow it down to the last-good
> commit.
>
> An issue report that identifies the commit/PR introducing the error should
> make it a quicker fix; if you're thinking of tackling the fix itself but
> need help figuring out where to start, it may help to fish around on the
> separate development list
>
> HTH,
> Travis
>
>
> On Wed, Jan 30, 2019 at 5:51 PM Ryan S. Elliott <rel...@um...> wrote:
>
>> Hello,
>>
>> Thanks for the reply.
>>
>> I tried 1.8.11 on my mac and I get a Segmentation fault!
>>
>> .
>> .
>> .
>> Reading
>> /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
>> Parsing file
>> /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
>> /bin/sh: line 1: 54543 Segmentation fault: 11
>> /Users/relliott/doxygen/build/bin/doxygen
>> /Users/relliott/unison-sync/KIM/git/kim-api/build/docs/Doxyfile.docs
>>
>>
>> Anyway, then I set up a ubuntu VM and got it to work.  Indeed, 1.8.11 on
>> ubuntu
>> it seems I get the same output as RTD.  I've also confirmed that 1.8.14 on
>> ubuntu produces the same output (without the interfaces documented) that I
>> previously obtained on my mac.
>>
>>
>> So, it seems that this is a regression in behavior from 1.8.11 to 1.8.14?
>> How
>> should I go about figuring out when/where this happened and what to do
>> about
>> it?
>>
>>
>>
>> On Wed, 30 Jan 2019, Travis Everett wrote:
>>
>>> The copy on RTD indicates it was generated by doxygen 1.8.11, while the
>> one
>>> at openkim indicates 1.8.14; a good first step would be installing 1.8.11
>>> and seeing if your output matches what's on RTD.
>>>
>>> On Wed, Jan 30, 2019 at 3:08 PM Ryan S. Elliott <rel...@um...>
>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm working on the doxygen documentation for the kim-api project
>>>> (https://github.com/openkim/kim-api)
>>>>
>>>> When I locally (on my mac) generate the doxygen docs I see problems with
>>>> the
>>>> fortran docs.  In particular, there are a fair number of functions that
>>>> are not
>>>> automatically documented by the parser.  Further, no generic interfaces
>> are
>>>> documented.
>>>>
>>>> However, the exact same git commit, when used to generate the doxygen
>> docs
>>>> by
>>>> readthedocs documents all the functions and generates the generic
>> interface
>>>> docs.
>>>>
>>>> Here is a link to a readthedocs page showing the interfaces:
>>>>
>> https://kim-api.readthedocs.io/en/latest/namespacekim__model__module.html
>>>>
>>>> Here is a link to a similar page generated locally:
>>>>
>> https://openkim.org/kim-api/docs-beta.3/namespacekim__model__module.html
>>>>
>>>> In particular, also notice that in the locally generated docs the
>>>> "kim_model_is_routine_present" function is not documented!
>>>>
>>>>
>>>> I can't understand why these differences are occuring.  Can anyone point
>>>> me in
>>>> the right direction?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Ryan Elliott
>>>>
>>>>
>>>> _______________________________________________
>>>> Doxygen-users mailing list
>>>> Dox...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>>>
>>>
>>
>> --
>> Ryan S. Elliott, Ph.D. and Professor
>> Aerospace Engineering & Mechanics, University of Minnesota
>> (612) 624-2376 (626-1558 fax)
>> https://z.umn.edu/relliott
>> download vCard <https://z.umn.edu/relliott_vcf>
>> ----------
>> The distinction between past, present and future, is only an illusion, even
>>     if a stubborn one.
>>
>>                                                             Albert Einstein
>> ----------
>>
>

-- 
Ryan S. Elliott, Ph.D. and Professor
Aerospace Engineering & Mechanics, University of Minnesota
(612) 624-2376 (626-1558 fax)
https://z.umn.edu/relliott
download vCard <https://z.umn.edu/relliott_vcf>
----------
Theoretical crystallography is too difficult for crystallographers.

                                           Hans Wondratschek, June 22, 2009
----------

Re: [Doxygen-users] difference between readthedocs generated and local

[Travis E. <tra...@gm...>]

Ryan,

I don't know a ton about how those parts of the codebase work so I stalled
a bit hoping someone else would respond (there's some chance I'll mis-lead
you here...). In any case, a good place to start is by seeing whether the
behavior changed in 1.8.12/13/14. That should let you narrow your focus to
just commits in a single version.

If you aren't set up to build Doxygen from source (and/or aren't
comfortable doing so), it's probably fine to open an issue report with the
behavior you've seen, which version changed it, and a minimal set of
files/config necessary to reproduce it. If you are comfortable building
from source you can push this further and identify the specific commit.

Hopefully the issue you're seeing was caused by an update to
src/fortranscanner.i or src/fortrancode.i (there are probably only a few
commits touching those per version). You can use git or github to identify
which commits between two versions touched either of those files, and
recompile/rebuild (depending on how long your docs take to build you may be
able to speed this up a lot by making a separate config that just includes
the minimum set of files you need to see the behavior) at each to see which
introduces the break.

If that doesn't work (or if there are more commits than I suspect touching
those two files) you can use the more general git bisect command (along
with a recompile and rebuild doc cycle) to narrow it down to the last-good
commit.

An issue report that identifies the commit/PR introducing the error should
make it a quicker fix; if you're thinking of tackling the fix itself but
need help figuring out where to start, it may help to fish around on the
separate development list

HTH,
Travis


On Wed, Jan 30, 2019 at 5:51 PM Ryan S. Elliott <rel...@um...> wrote:

> Hello,
>
> Thanks for the reply.
>
> I tried 1.8.11 on my mac and I get a Segmentation fault!
>
> .
> .
> .
> Reading
> /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
> Parsing file
> /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
> /bin/sh: line 1: 54543 Segmentation fault: 11
> /Users/relliott/doxygen/build/bin/doxygen
> /Users/relliott/unison-sync/KIM/git/kim-api/build/docs/Doxyfile.docs
>
>
> Anyway, then I set up a ubuntu VM and got it to work.  Indeed, 1.8.11 on
> ubuntu
> it seems I get the same output as RTD.  I've also confirmed that 1.8.14 on
> ubuntu produces the same output (without the interfaces documented) that I
> previously obtained on my mac.
>
>
> So, it seems that this is a regression in behavior from 1.8.11 to 1.8.14?
> How
> should I go about figuring out when/where this happened and what to do
> about
> it?
>
>
>
> On Wed, 30 Jan 2019, Travis Everett wrote:
>
> > The copy on RTD indicates it was generated by doxygen 1.8.11, while the
> one
> > at openkim indicates 1.8.14; a good first step would be installing 1.8.11
> > and seeing if your output matches what's on RTD.
> >
> > On Wed, Jan 30, 2019 at 3:08 PM Ryan S. Elliott <rel...@um...>
> wrote:
> >
> >> Hello,
> >>
> >> I'm working on the doxygen documentation for the kim-api project
> >> (https://github.com/openkim/kim-api)
> >>
> >> When I locally (on my mac) generate the doxygen docs I see problems with
> >> the
> >> fortran docs.  In particular, there are a fair number of functions that
> >> are not
> >> automatically documented by the parser.  Further, no generic interfaces
> are
> >> documented.
> >>
> >> However, the exact same git commit, when used to generate the doxygen
> docs
> >> by
> >> readthedocs documents all the functions and generates the generic
> interface
> >> docs.
> >>
> >> Here is a link to a readthedocs page showing the interfaces:
> >>
> https://kim-api.readthedocs.io/en/latest/namespacekim__model__module.html
> >>
> >> Here is a link to a similar page generated locally:
> >>
> https://openkim.org/kim-api/docs-beta.3/namespacekim__model__module.html
> >>
> >> In particular, also notice that in the locally generated docs the
> >> "kim_model_is_routine_present" function is not documented!
> >>
> >>
> >> I can't understand why these differences are occuring.  Can anyone point
> >> me in
> >> the right direction?
> >>
> >>
> >> Thanks,
> >>
> >> Ryan Elliott
> >>
> >>
> >> _______________________________________________
> >> Doxygen-users mailing list
> >> Dox...@li...
> >> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >>
> >
>
> --
> Ryan S. Elliott, Ph.D. and Professor
> Aerospace Engineering & Mechanics, University of Minnesota
> (612) 624-2376 (626-1558 fax)
> https://z.umn.edu/relliott
> download vCard <https://z.umn.edu/relliott_vcf>
> ----------
> The distinction between past, present and future, is only an illusion, even
>     if a stubborn one.
>
>                                                             Albert Einstein
> ----------
>

[Doxygen-users] EXTRACT_ALL and python

[Olivier C. <Oli...@ce...>]

Hi,

Some time ago I asked the same question but got no answer.
So I ask again.

Why when I have EXTRACT_ALL=Yes the python scripts I have
are listed as C++ Namespaces ?

Chees,
OC

Re: [Doxygen-users] difference between readthedocs generated and local

[Ryan S. E. <rel...@um...>]

Hello,

Thanks for the reply.

I tried 1.8.11 on my mac and I get a Segmentation fault!

.
.
.
Reading /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
Parsing file /Users/relliott/unison-sync/KIM/git/kim-api/fortran/include/kim_model_compute_arguments_module.f90...
/bin/sh: line 1: 54543 Segmentation fault: 11  /Users/relliott/doxygen/build/bin/doxygen /Users/relliott/unison-sync/KIM/git/kim-api/build/docs/Doxyfile.docs


Anyway, then I set up a ubuntu VM and got it to work.  Indeed, 1.8.11 on ubuntu 
it seems I get the same output as RTD.  I've also confirmed that 1.8.14 on 
ubuntu produces the same output (without the interfaces documented) that I 
previously obtained on my mac.


So, it seems that this is a regression in behavior from 1.8.11 to 1.8.14?  How 
should I go about figuring out when/where this happened and what to do about 
it?



On Wed, 30 Jan 2019, Travis Everett wrote:

> The copy on RTD indicates it was generated by doxygen 1.8.11, while the one
> at openkim indicates 1.8.14; a good first step would be installing 1.8.11
> and seeing if your output matches what's on RTD.
>
> On Wed, Jan 30, 2019 at 3:08 PM Ryan S. Elliott <rel...@um...> wrote:
>
>> Hello,
>>
>> I'm working on the doxygen documentation for the kim-api project
>> (https://github.com/openkim/kim-api)
>>
>> When I locally (on my mac) generate the doxygen docs I see problems with
>> the
>> fortran docs.  In particular, there are a fair number of functions that
>> are not
>> automatically documented by the parser.  Further, no generic interfaces are
>> documented.
>>
>> However, the exact same git commit, when used to generate the doxygen docs
>> by
>> readthedocs documents all the functions and generates the generic interface
>> docs.
>>
>> Here is a link to a readthedocs page showing the interfaces:
>> https://kim-api.readthedocs.io/en/latest/namespacekim__model__module.html
>>
>> Here is a link to a similar page generated locally:
>> https://openkim.org/kim-api/docs-beta.3/namespacekim__model__module.html
>>
>> In particular, also notice that in the locally generated docs the
>> "kim_model_is_routine_present" function is not documented!
>>
>>
>> I can't understand why these differences are occuring.  Can anyone point
>> me in
>> the right direction?
>>
>>
>> Thanks,
>>
>> Ryan Elliott
>>
>>
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>
>

-- 
Ryan S. Elliott, Ph.D. and Professor
Aerospace Engineering & Mechanics, University of Minnesota
(612) 624-2376 (626-1558 fax)
https://z.umn.edu/relliott
download vCard <https://z.umn.edu/relliott_vcf>
----------
The distinction between past, present and future, is only an illusion, even
    if a stubborn one.

                                                            Albert Einstein
----------

Re: [Doxygen-users] difference between readthedocs generated and local

[Travis E. <tra...@gm...>]

The copy on RTD indicates it was generated by doxygen 1.8.11, while the one
at openkim indicates 1.8.14; a good first step would be installing 1.8.11
and seeing if your output matches what's on RTD.

On Wed, Jan 30, 2019 at 3:08 PM Ryan S. Elliott <rel...@um...> wrote:

> Hello,
>
> I'm working on the doxygen documentation for the kim-api project
> (https://github.com/openkim/kim-api)
>
> When I locally (on my mac) generate the doxygen docs I see problems with
> the
> fortran docs.  In particular, there are a fair number of functions that
> are not
> automatically documented by the parser.  Further, no generic interfaces are
> documented.
>
> However, the exact same git commit, when used to generate the doxygen docs
> by
> readthedocs documents all the functions and generates the generic interface
> docs.
>
> Here is a link to a readthedocs page showing the interfaces:
> https://kim-api.readthedocs.io/en/latest/namespacekim__model__module.html
>
> Here is a link to a similar page generated locally:
> https://openkim.org/kim-api/docs-beta.3/namespacekim__model__module.html
>
> In particular, also notice that in the locally generated docs the
> "kim_model_is_routine_present" function is not documented!
>
>
> I can't understand why these differences are occuring.  Can anyone point
> me in
> the right direction?
>
>
> Thanks,
>
> Ryan Elliott
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

[Doxygen-users] difference between readthedocs generated and local

[Ryan S. E. <rel...@um...>]

Hello,

I'm working on the doxygen documentation for the kim-api project
(https://github.com/openkim/kim-api)

When I locally (on my mac) generate the doxygen docs I see problems with the
fortran docs.  In particular, there are a fair number of functions that are not
automatically documented by the parser.  Further, no generic interfaces are
documented.

However, the exact same git commit, when used to generate the doxygen docs by
readthedocs documents all the functions and generates the generic interface
docs.

Here is a link to a readthedocs page showing the interfaces:
https://kim-api.readthedocs.io/en/latest/namespacekim__model__module.html

Here is a link to a similar page generated locally:
https://openkim.org/kim-api/docs-beta.3/namespacekim__model__module.html

In particular, also notice that in the locally generated docs the
"kim_model_is_routine_present" function is not documented!


I can't understand why these differences are occuring.  Can anyone point me in
the right direction?


Thanks,

Ryan Elliott

[Doxygen-users] How to keep class/documentation in html output

[Andy H. <a.h...@op...>]

Hi,

We use a lot of additional pages in markdown format to complement our 
source code to produce HTML-based documentation, e.g.:

     https://www.openfoam.com/documentation/guides/latest/doc/

It works well, except that all output files are written to a single 
directory.  To work around this we typically build the hierarchy into 
the file name, e.g. on disk the source file:

     foo/bar/baz.md

is renamed

     foo/bar/foo-bar-baz.md

leading to the final documentation file being output as

     <out-dir>/foo-bar-baz.html

Is there a way to output the (HTML) documentation using the same folder 
hierarchy that was used for the input files? i.e.

     <out-dir>/foo/bar/baz.html

There's a similar posting on stack exchange here from 2014:

     
https://stackoverflow.com/questions/24850664/customize-the-doxygen-to-output-the-html-file-in-class-hierarchy

Thanks,
Andy

[Doxygen-users] Doxygen: longtabu and MiKTeX

[Paolo G. <pj...@ev...>]

Dear all,

This is my first mail in the list. thanks for the great software you made!

We are integrating Doxygen in our project
(https://github.com/evidence/erika3), and we are facing a few issues on
the Latex export on windows.

The current status is as follows:

On Linux:
- Ubuntu 18.04
- doxygen 1.8.13
- standard latex distribution, with longtabu version:
  tabu : 2011/02/26 v2.8 - tabu : Flexible LaTeX tabulars
- Everything ok, both HTML and Latex export!

On Windows
- Miktex updated to the last distribution, with longtabu version:
    tabu : 2019-01-11 - tabu : Flexible LaTeX tabulars
    Updated 2019-01-11
    see https://github.com/tabu-fixed/tabu
- Doxygen for windows 1.8.11, 1.8.14, 1.8.15 (the latest)
- HTML export ok
- Latex export NOT ok


On windows, it seems that longtabu has strange issues. In particular, it
fails on even small tables generated either from markdown or from HTML
conversion, with an error as follows:

--------------------------
[...]
! Missing } inserted.
<inserted text>
                }
l.26 \end{longtabu}

?
--------------------------

I wonder if anyone had the same issue in the latest days. Could it be
due to the recent update on the tabu package in miktex?

Regards,

Paolo