Re: Using AsciiDoc for Documentation

[Rob Gowin]

> On Sep 1, 2015, at 4:56 AM, Mike Evans  wrote:
>> [snip]
> 
> Hi Rob
> 
> Looks good to me. Still a few minor bugs with the Asciidoc.  
> 
> Some of the Figure titles are missing
> Second level bullet indents missing
> 
> But these are minor and some tweaking of the XSL should fix that.  Speaking 
> of which, I notice the XSL isn't in github can you make that available 
> somewhere so others can chip in with help? I'd also like to generate the 
> Asciidoc locally so I can ensure both formats are from the same source for 
> comparison purposes.
> 
> Now you (we) have to convince others to use Asciidoc!
> 
> I use Geany for my coding/writing and there is a Markdown plugin for preview, 
> no Asciidoc at the moment though.  I'm looking at the PEG code to see how 
> difficult it would be to produce an Asciidoc previewer plugin.  It may be 
> beyond my learning tolerance though.
> 
> Mike E
> 
> 
> 
> -- 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53  


Hi Mike,

Thanks for taking a look. I have put the XSL file and a python
script to run the conversion process in a repository at 
https://github.com/codesmythe/asciidoc-conversion. See the README
there for details.

As for editors, I just use a command line converter and then
reload the generated HTML into a browser. I need to try some of the
live preview editors mentioned in the link you sent out yesterday.

I'll look at the issues you mentioned in the next couple of days.

Thanks,

Rob




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

On 9/1/2015 5:13 PM, John Ralls wrote:
>> On Aug 28, 2015, at 8:17 PM, John Ralls  wrote:
>>
>>
>>> On Aug 28, 2015, at 6:43 AM, Geert Janssens  
>>> wrote:
>>>
>>> On Friday 28 August 2015 08:55:53 John Ralls wrote:
 I’ve pushed a feature branch, single-price, to my Github repo
 (https://github.com/jralls/gnucash ) 
 which covers most of what we’ve
 discussed here. I’m still wrestling with the math of how to sensibly
 handle rounding itself, so what’s there still uses the hard-coded
 10^6 denom. The branch is from maint because I’d like to put these
 changes in 2.6.8.

 The actual changes are explained in the commit notes. In my limited
 testing it appears to work and to provide stability when doing
 multiple transactions with the same exchange rate. Please test some
 more; I’m sure I didn’t think of every possible variation.

>>> Hi John,
>>>
>>> Thanks for your work on this.
>>>
>>> From my first tests and reading the code I have the following observations:
>>>
>>> - Let me start with a nit-pick: while reading through the commits I got 
>>> confused by the return values of check_account and check_edit. They return 
>>> TRUE if the check fails (that is when anything is not ok to continue with a 
>>> transfer). From a distance that seems backwards. I usually expect a check 
>>> function to return TRUE if all checks pass correctly.
>>>
>>> - Next I created a vendor bill, posted it and then paid it in a foreign 
>>> currency. This also pops up the transfer dialog. I entered a price and 
>>> continued. This added the price to the db (as expected). Next I remove the 
>>> payment transaction (from the bank account in the foreign currency) and 
>>> issue a new payment via the payment dialog, again in the same foreign 
>>> currency. This time however, I enter a to amount directly (ensuring it 
>>> would result in a completely different price). Check the price db and note 
>>> the existing price hasn't changed.
>>>
>>> - The currencies I was playing with are € (from currency) and HKD (to 
>>> currency). Before your changes my price db listed a HKD security EUR 
>>> currency. On your branch the code now adds a EUR security in HKD currency. 
>>> That change is fine in itself. I prefer your normalized way to store 
>>> (currency) exchange rates in the db. The issue with this however is that 
>>> F::Q won't return an exchange rate for the new price, while it did (and 
>>> still does) for the old one.
>>>
 As for the math, here’s the conundrum: I proposed earlier to base the
 rounding on what would make a 1 scu change in the “to” commodity. The
 problems with that idea are that it depends entirely on the amount in
 the “from” commodity and that prices are often quoted in fractions of
 a scu. For example, the Wall Street Journal website quotes the Yen at
 120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
 make a 1¥ change in the value is different if the USD amount is $10
 from what it would be if the amount was $1000. Carry that to its
 illogical conclusion and we need infinite precision, and that’s
 ignoring the fact that we need infinite precision to exactly
 represent a lot of rational fractions, but since all the real money
 systems use decimal math nowadays that’s not really germane.

 So I have a new proposal: If the commodities are both currencies,
 store exchange rates in the direction where the rate > 1, set the
 denominator to 1000, and round-half-up. The price retrieval code
 already checks in both directions. If only one of the commodities is
 a currency then it’s a price and we store it in the currency with the
 denominator = the currency’s scu * 1.

>>> See above: the check in both directions is not reliable/borked.
>>>
 That leaves commodity-commodity prices. The most common example in
 modern life is stock-for-stock exchanges resulting from mergers or
 spin-offs. These tend to be one-offs, so no rounding required. Barter
 exchange, where one exchanges one commodity for another (e.g. two
 bushels of corn for a cow), is similarly fractional rather than
 decimal, so again not rounding is appropriate. The third case is the
 problem: Bitcoin and similar pseudo-currencies. For maint I think
 we’re going to have to leave those prices unrounded as well, but
 perhaps for master we should consider creating a separate commodity
 category so that users can create commodities that GnuCash treats as
 currencies.

>>> That looks like a very sensible proposal to me.
>> Geert,
>>
>> Thanks for testing. I agree that the check_foo() semantics are clumsy. I did 
>> it that way to avoid negating the return value in the if conditional, but in 
>> retrospect that would be clearer, so I’ll flip it.
>>
>> Roger that the checks aren’t reliably 

Re: Rounding in the price db.

[John Ralls]

> On Aug 28, 2015, at 8:17 PM, John Ralls  wrote:
> 
> 
>> On Aug 28, 2015, at 6:43 AM, Geert Janssens  
>> wrote:
>> 
>> On Friday 28 August 2015 08:55:53 John Ralls wrote:
>>> I’ve pushed a feature branch, single-price, to my Github repo
>>> (https://github.com/jralls/gnucash ) 
>>> which covers most of what we’ve
>>> discussed here. I’m still wrestling with the math of how to sensibly
>>> handle rounding itself, so what’s there still uses the hard-coded
>>> 10^6 denom. The branch is from maint because I’d like to put these
>>> changes in 2.6.8.
>>> 
>>> The actual changes are explained in the commit notes. In my limited
>>> testing it appears to work and to provide stability when doing
>>> multiple transactions with the same exchange rate. Please test some
>>> more; I’m sure I didn’t think of every possible variation.
>>> 
>> Hi John,
>> 
>> Thanks for your work on this.
>> 
>> From my first tests and reading the code I have the following observations:
>> 
>> - Let me start with a nit-pick: while reading through the commits I got 
>> confused by the return values of check_account and check_edit. They return 
>> TRUE if the check fails (that is when anything is not ok to continue with a 
>> transfer). From a distance that seems backwards. I usually expect a check 
>> function to return TRUE if all checks pass correctly.
>> 
>> - Next I created a vendor bill, posted it and then paid it in a foreign 
>> currency. This also pops up the transfer dialog. I entered a price and 
>> continued. This added the price to the db (as expected). Next I remove the 
>> payment transaction (from the bank account in the foreign currency) and 
>> issue a new payment via the payment dialog, again in the same foreign 
>> currency. This time however, I enter a to amount directly (ensuring it would 
>> result in a completely different price). Check the price db and note the 
>> existing price hasn't changed.
>> 
>> - The currencies I was playing with are € (from currency) and HKD (to 
>> currency). Before your changes my price db listed a HKD security EUR 
>> currency. On your branch the code now adds a EUR security in HKD currency. 
>> That change is fine in itself. I prefer your normalized way to store 
>> (currency) exchange rates in the db. The issue with this however is that 
>> F::Q won't return an exchange rate for the new price, while it did (and 
>> still does) for the old one.
>> 
>>> As for the math, here’s the conundrum: I proposed earlier to base the
>>> rounding on what would make a 1 scu change in the “to” commodity. The
>>> problems with that idea are that it depends entirely on the amount in
>>> the “from” commodity and that prices are often quoted in fractions of
>>> a scu. For example, the Wall Street Journal website quotes the Yen at
>>> 120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
>>> make a 1¥ change in the value is different if the USD amount is $10
>>> from what it would be if the amount was $1000. Carry that to its
>>> illogical conclusion and we need infinite precision, and that’s
>>> ignoring the fact that we need infinite precision to exactly
>>> represent a lot of rational fractions, but since all the real money
>>> systems use decimal math nowadays that’s not really germane.
>>> 
>>> So I have a new proposal: If the commodities are both currencies,
>>> store exchange rates in the direction where the rate > 1, set the
>>> denominator to 1000, and round-half-up. The price retrieval code
>>> already checks in both directions. If only one of the commodities is
>>> a currency then it’s a price and we store it in the currency with the
>>> denominator = the currency’s scu * 1.
>>> 
>> See above: the check in both directions is not reliable/borked.
>> 
>>> That leaves commodity-commodity prices. The most common example in
>>> modern life is stock-for-stock exchanges resulting from mergers or
>>> spin-offs. These tend to be one-offs, so no rounding required. Barter
>>> exchange, where one exchanges one commodity for another (e.g. two
>>> bushels of corn for a cow), is similarly fractional rather than
>>> decimal, so again not rounding is appropriate. The third case is the
>>> problem: Bitcoin and similar pseudo-currencies. For maint I think
>>> we’re going to have to leave those prices unrounded as well, but
>>> perhaps for master we should consider creating a separate commodity
>>> category so that users can create commodities that GnuCash treats as
>>> currencies.
>>> 
>> That looks like a very sensible proposal to me.
> 
> Geert,
> 
> Thanks for testing. I agree that the check_foo() semantics are clumsy. I did 
> it that way to avoid negating the return value in the if conditional, but in 
> retrospect that would be clearer, so I’ll flip it.
> 
> Roger that the checks aren’t reliably bidirectional. I’ll dig into that. I 
> hadn’t yet changed anything with regards to which direction prices are 

Re: Doxygen Warnings

[John Ralls]

> On Sep 1, 2015, at 2:53 PM, Matt Graham  wrote:
> 
> Thanks John,
> 
> I'm running doxygen directly on the src directory of the code.
> 
> Windows 8.1 at the moment. I'm travelling for work at the moment, when I get 
> home over the weekend I'll try it on my gentoo box too

Matt,

That probably explains your trouble. You can either use `make docs` or copy all 
of the configuration from it into your Doxygen setup. Make will be easier if 
you have a Mingw build setup, but getting that might not be worth it just to 
run Doxygen.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Doxygen Warnings

[Matt Graham]

Thanks John,

I'm running doxygen directly on the src directory of the code.

Windows 8.1 at the moment. I'm travelling for work at the moment, when I get 
home over the weekend I'll try it on my gentoo box too

Cheers,
Matt /|\

 John Ralls wrote 


> On Sep 1, 2015, at 2:04 AM, Matt Graham  wrote:
>
> I think I might have a mistake in my doxygen configuration. When generating 
> from the source (obtained by cloning Github repository) I get nearly 450 
> warnings.
>
>
> A lot of these relate to references that aren't found. Immediately, on the 
> index.htm page I notice that only one of all the links under “Doxygen 
> Overviews” has been created successfully. Has anyone else generated the 
> documentation from the current source and have you had a similar problem?

Matt,

The docs are built nightly (you can find them at 
http://code.gnucash.org/docs/HEAD) and built last night. I ran Doxygen locally 
a month or so ago without trouble. Did you try running Doxygen by hand or did 
you `make docs`? What OS/distro?

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Doxygen Warnings

[Matt Graham]

I think I might have a mistake in my doxygen configuration. When generating 
from the source (obtained by cloning Github repository) I get nearly 450 
warnings. 


A lot of these relate to references that aren't found. Immediately, on the 
index.htm page I notice that only one of all the links under “Doxygen 
Overviews” has been created successfully. Has anyone else generated the 
documentation from the current source and have you had a similar problem?






Thanks and regards,

Matt Graham
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Doxygen Code Documentation

[Matt Graham]

Thanks for responding so quickly guys!


FYI John, I’m not planning on commenting line by line - just commenting all the 
methods/variables/structures so that people can see how things interact whilst 
browsing doxygen pages. I’ll try to get around to reading your recommended 
book, but it probably wont be for a few days.


I like Derek's idea of commenting blocks of code, but I'll probably only do 
this for areas that look really hard to understand (and probably more for 
myself than for submission).





Thanks and regards,

Matt Graham





From: Derek Atkins
Sent: ‎Tuesday‎, ‎1‎ ‎September‎ ‎2015 ‎01‎:‎13‎ ‎
To: John Ralls
Cc: Matt Graham, gnucash-devel@gnucash.org





John Ralls  writes:

> Some programmers, often less-experienced ones, will comment code
> liberally to explain what they’re doing. More experienced programmers
> often find this irritating because they’re fluent enough in the
> programming language that they can understand the code without the
> comments and the comments just get in the way. Those programmers
> prefer a brief descriptive comment only when the author finds it
> necessary to do something non-ideomatic.

I dunno; I consider myself an experienced programmer and I like
documenting my algorithms (to explain how chunks of code work).  I don't
necessarily comment each line (e.g., I wouldn't be in a comment
"increment x" next to or above "x++;") but I do like to, even 10-20
lines or so, put in a comment about what the block of code is supposed
to do.

If nothing else it helps me when I revisit the code a year later to get
myself back into the mindset, otherwise I wind up going "what was I
THINKING when I wrote that?"

> None of which should be taken as a defense of GnuCash’s code or API
> documentation. A lot of the code is a turgid, unideomatic mess with
> several-hundred-line functions calling all over the place and
> sometimes flipping back and forth between Scheme and C. Writing bug
> reports about it won’t be helpful unless you submitting a patch, and
> then only if it’s a good patch that improves code readability,
> testability, or Doxygen documentation. If that’s the sort of work you
> want to take on, Welcome! If you haven’t already, get a copy of Martin
> Fowler’s “Refactoring” and study it: It’s the bible for fixing ugly
> code.
>
> Regards,
> John Ralls

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using AsciiDoc for Documentation

[Mike Evans]

On Sun, 30 Aug 2015 19:16:24 -0500
Rob Gowin  wrote:

> [Hello List. Long time GnuCash user, -devel list lurker,
>  coming out of the shadows.]
> 
> > On Aug 29, 2015, at 5:43 AM, Mike Evans  wrote:
> > Another random thought then.
> >
> > I use asciidoc for pretty much all the docs I write, not much
> > admittedly but it's easy to learn and can produce many output formats.
> > I just used https://github.com/oreillymedia/docbook2asciidoc to
> > convert the guide to asciidoc using:
> >
> > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar
> > -s gnucash-guide.xml -o gnucash-guide.asc
> > /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true
> >
> > This produces an asccidoc file for each chapter plus the master page.
> >
> > [...]
> >
> > I'm not an expert on XML parsing using .xsl stylesheets but I suspect
> > this could be easily(?) remedied by editing the d2a.xsl to correctly
> > include the figures[...]
> 
> I am also a fan of using AsciiDoc as a documentation format. A
> while back I did some of the XSL hacking Mike refers to that is needed
> to get a decent conversion from the existing DocBook files. It's to
> the point where I would like to get some feedback.
> 
> I've done a first-pass conversion of the English version of the T & CG to
> AsciiDoc at https://github.com/codesmythe/gnucash-docs/tree/asciidoc/guide/C
> .
> You can click on the *.asc files there like ch_oview.asc to see GitHub's
> rendered verison of the file, including non-SVG images. (Note that SVG files
> and inter-chapter links don't work on GitHub's render.) You can click on the
> 'Raw' button for a file to see the AsciiDoc source. The source needs  clean
> up
> (lines too long, etc), but it is clean enough for folks to get an idea of
> the
> syntax. The GitHub web interace is useful because I think small edits could
> be
> done and sent as pull requests all from the web.
> 
> Like Mike said, the AsciiDoc tools (asciidoctor, at http://asciidoctor.org
> in
> this case) support the generation of DocBook XML files, so it's relatively
> simple to insert AsciiDoc support into the  current document generation
> flow.
> The asciidoctor tool generates DocBook output, and the existing flow for
> generating PDFs, HTML, EPUB, MOBI etc. works the same. My branch has the
> changes to the various Makefile.am files to support this. Those interested
> should be able to clone the repo, switch to the asciidoc branch and then
> 'make
> pdf' as usual. Note that the 'configure' script will expect to find the
> asciidoctor program on the system. I think the generated PDF is reasonably
> close to the original for a first pass proof of concept.  I've tested the
> flow
> on OS X and Fedora 21. Dunno about Windows.
> 
> Hopefully this little demo can move the documentation file format
> discussion
> forward a bit. :-) Thoughts?
> 
> 
> Regards,
> 
> Rob

Hi Rob

Looks good to me. Still a few minor bugs with the Asciidoc.  

Some of the Figure titles are missing
Second level bullet indents missing

But these are minor and some tweaking of the XSL should fix that.  Speaking of 
which, I notice the XSL isn't in github can you make that available somewhere 
so others can chip in with help? I'd also like to generate the Asciidoc locally 
so I can ensure both formats are from the same source for comparison purposes.

Now you (we) have to convince others to use Asciidoc!

I use Geany for my coding/writing and there is a Markdown plugin for preview, 
no Asciidoc at the moment though.  I'm looking at the PEG code to see how 
difficult it would be to produce an Asciidoc previewer plugin.  It may be 
beyond my learning tolerance though.

Mike E



-- 
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53  
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LaTex for Documentation

[Ted Creedon]

whats wrong with Latex?

It works fine and produces a permuted index too

tedc


From: gnucash-devel  
on behalf of Mike Evans 
Sent: Tuesday, September 1, 2015 2:56 AM
Cc: gnucash-devel@gnucash.org
Subject: Re: Using AsciiDoc for Documentation

On Sun, 30 Aug 2015 19:16:24 -0500
Rob Gowin  wrote:

> [Hello List. Long time GnuCash user, -devel list lurker,
>  coming out of the shadows.]
>
> > On Aug 29, 2015, at 5:43 AM, Mike Evans  wrote:
> > Another random thought then.
> >
> > I use asciidoc for pretty much all the docs I write, not much
> > admittedly but it's easy to learn and can produce many output formats.
> > I just used https://github.com/oreillymedia/docbook2asciidoc to
> > convert the guide to asciidoc using:
> >
> > $ java -jar /home/mikee/Projects/docbook2asciidoc/saxon9he.jar
> > -s gnucash-guide.xml -o gnucash-guide.asc
> > /home/mikee/Projects/docbook2asciidoc/d2a.xsl  chunk-output=true
> >
> > This produces an asccidoc file for each chapter plus the master page.
> >
> > [...]
> >
> > I'm not an expert on XML parsing using .xsl stylesheets but I suspect
> > this could be easily(?) remedied by editing the d2a.xsl to correctly
> > include the figures[...]
>
> I am also a fan of using AsciiDoc as a documentation format. A
> while back I did some of the XSL hacking Mike refers to that is needed
> to get a decent conversion from the existing DocBook files. It's to
> the point where I would like to get some feedback.
>
> I've done a first-pass conversion of the English version of the T & CG to
> AsciiDoc at https://github.com/codesmythe/gnucash-docs/tree/asciidoc/guide/C
> .
> You can click on the *.asc files there like ch_oview.asc to see GitHub's
> rendered verison of the file, including non-SVG images. (Note that SVG files
> and inter-chapter links don't work on GitHub's render.) You can click on the
> 'Raw' button for a file to see the AsciiDoc source. The source needs  clean
> up
> (lines too long, etc), but it is clean enough for folks to get an idea of
> the
> syntax. The GitHub web interace is useful because I think small edits could
> be
> done and sent as pull requests all from the web.
>
> Like Mike said, the AsciiDoc tools (asciidoctor, at http://asciidoctor.org
> in
> this case) support the generation of DocBook XML files, so it's relatively
> simple to insert AsciiDoc support into the  current document generation
> flow.
> The asciidoctor tool generates DocBook output, and the existing flow for
> generating PDFs, HTML, EPUB, MOBI etc. works the same. My branch has the
> changes to the various Makefile.am files to support this. Those interested
> should be able to clone the repo, switch to the asciidoc branch and then
> 'make
> pdf' as usual. Note that the 'configure' script will expect to find the
> asciidoctor program on the system. I think the generated PDF is reasonably
> close to the original for a first pass proof of concept.  I've tested the
> flow
> on OS X and Fedora 21. Dunno about Windows.
>
> Hopefully this little demo can move the documentation file format
> discussion
> forward a bit. :-) Thoughts?
>
>
> Regards,
>
> Rob

Hi Rob

Looks good to me. Still a few minor bugs with the Asciidoc.

Some of the Figure titles are missing
Second level bullet indents missing

But these are minor and some tweaking of the XSL should fix that.  Speaking of 
which, I notice the XSL isn't in github can you make that available somewhere 
so others can chip in with help? I'd also like to generate the Asciidoc locally 
so I can ensure both formats are from the same source for comparison purposes.

Now you (we) have to convince others to use Asciidoc!

I use Geany for my coding/writing and there is a Markdown plugin for preview, 
no Asciidoc at the moment though.  I'm looking at the PEG code to see how 
difficult it would be to produce an Asciidoc previewer plugin.  It may be 
beyond my learning tolerance though.

Mike E



--
PGP key:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x00CDB13500D7AB53
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Doxygen Code Documentation

[John Ralls]

> On Sep 1, 2015, at 1:43 AM, Matt Graham  wrote:
> 
> Thanks for responding so quickly guys!
> 
> FYI John, I’m not planning on commenting line by line - just commenting all 
> the methods/variables/structures so that people can see how things interact 
> whilst browsing doxygen pages. I’ll try to get around to reading your 
> recommended book, but it probably wont be for a few days.
> 
> I like Derek's idea of commenting blocks of code, but I'll probably only do 
> this for areas that look really hard to understand (and probably more for 
> myself than for submission).

Matt,

Just to be clear, Doxygen comments should describe how to use a function: What 
it does, variables, return values, and side effects, etc. How the function 
works should be in plain comments and should be limited to explaining bits that 
are “hard to understand”, i.e. not idiomatic. 

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Using LaTex for Documentation

[John Ralls]

> On Sep 1, 2015, at 3:38 AM, Ted Creedon  wrote:
> 
> whats wrong with Latex?
> 
> It works fine and produces a permuted index too

Besides being even geekier and harder to convert to ePub and HTML than Docbook? 
Probably nothing much.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Doxygen Warnings

[John Ralls]

> On Sep 1, 2015, at 2:04 AM, Matt Graham  wrote:
> 
> I think I might have a mistake in my doxygen configuration. When generating 
> from the source (obtained by cloning Github repository) I get nearly 450 
> warnings. 
> 
> 
> A lot of these relate to references that aren't found. Immediately, on the 
> index.htm page I notice that only one of all the links under “Doxygen 
> Overviews” has been created successfully. Has anyone else generated the 
> documentation from the current source and have you had a similar problem?

Matt,

The docs are built nightly (you can find them at 
http://code.gnucash.org/docs/HEAD) and built last night. I ran Doxygen locally 
a month or so ago without trouble. Did you try running Doxygen by hand or did 
you `make docs`? What OS/distro?

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel