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 <marc.herb...@gmail.com> wrote: > Le ven. 8 févr. 2019 à 09:55, Travis Everett <travis.a.ever...@gmail.com> > 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 > >
_______________________________________________ Doxygen-users mailing list Doxygen-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/doxygen-users
