Re: [Doxygen-users] difference between readthedocs generated and local
Brought to you by:
dimitri
From: Ryan S. E. <rel...@um...> - 2019-08-13 12:56:18
|
Hello, Just wanted to follow up on this. We found the bug (a single missing character in a regex). A PR has been opened on github https://github.com/doxygen/doxygen/pull/7192 Cheers, Ryan On Thu, 31 Jan 2019, Ryan S. Elliott wrote: > 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> ---------- Words ought to be a little wild for they are the assaults of thought on the unthinking. John Maynard Keynes ---------- |