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 everythin
st 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
>
>
>
> 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
Le ven. 8 févr. 2019 à 09:55, Travis Everett 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 sa
Le ven. 8 févr. 2019 à 13:08, Travis Everett 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 delet
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
> 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 doxy
