Re: [julia] Make install cleaning and improvements (#8428)
Tony Kelman
Hm, we never backported this. Should we? Also #8398 would be necessary
—
Reply to this email directly or view it on GitHub.
Elliot Saba
I don't think this is urgent enough to backport; it's mostly stuff to make things more "correct", but doesn't fix any big bugs that I can tell.
Tony Kelman
Elliot Saba
No urgency, not really fixing a bug, but does reduce the number of fiddly conflicts if we want to backport #10253. I could probably limit that to just 94334bc for consistent naming on the buildbots though, and not backport the rest of it.
—
Reply to this email directly or view it on GitHub.
--You received this message because you are subscribed to the Google Groups "julia-backports" group.
To unsubscribe from this group and stop receiving emails from it, send an email to julia-backpor...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jameson Nash
i just got bit by this commit on master, since the files never get recopied from examples when they get modified. this either needs to be reverted to a symlink or written with proper makefile dependency update rules.
Jeff Waller
Tony Kelman
No, it's a "makefiles should never be written by humans" moment since no one ever seems to be able to write them perfectly.
Milan Bouchet-Valat
Makefiles are also particularly hard to test... As can be seen from the fact that nobody had noticed this bug for months. :-/
Ideally, $(build_docdir) should recursively depend on doc/ (and thus on examples/), so that it's copied again on every change. But it doesn't seem easy in make. We could just mark this as a PHONY target, but running it on every build would be silly. Any ideas?
Milan Bouchet-Valat
Bump!
Tony Kelman
would the directory timestamp be a decent proxy?
Milan Bouchet-Valat
Not AFAICT. Switching between two branches which have differences under doc/ does not update the timestamp. You need to create/delete a file for that (and, I think, only at the toplevel). That's really lousy.
Milan Bouchet-Valat
@staticfloat Do you have any ideas?
Elliot Saba
Take a look at this branch and let me know if it fixes it for you.
Milan Bouchet-Valat
@vtjnash I think you're the best person to check whether @staticfloat's fix works.
Jameson Nash
Wildcard is preferable to shell find, but you can't use directory timestamps for this, so it wouldn't be entirely reliably. A better option would be to put a dummy file in there and "touch" it at the end of the makefile rule.
Elliot Saba
Yes, the nice thing about $(shell find examples) is that it recurses.
I'm not sure how the dummy file would work? We want to re-rerun this command every time a file in examples changes, so how would the timestamp of the dummy file get updated when I edit e.g. examples/clustermanager/0mq/head.jl?
Jameson Nash
Good point about the recursion. The dummy file would be the target, since the timestamp of a folder target is unreliable.
Elliot Saba
What I mean is how does the timestamp of the dummy file get updated? As it stands, because $(shell find examples) explicitly lists out all the files contained within examples/, we have direct dependency on each file within examples/ and aren't relying on the directory timestamps at all. I suppose we could ask find to only list files and not include directories, but I'm not sure that would help anything.
Jameson Nash
touch $@
Jeff Waller
Following on, If you wanted to go down the find-touch route, then something like this might work:
find . -type f -exec touch {} \;
Or some-such. Sorry I have not been paying attention to this thread as much as I should.
Elliot Saba
I don't think we're talking about the same thing; we want to re-run these commands whenever an external program modifies the files; we don't want to change the timestamps from within the Makefile.