That's an interesting, and far less involved, possibility. Though not all dependency build tweaks / patches produce any new artifacts that weren't already there, they just generate the same ones in a modified way.
On Wednesday, October 29, 2014 11:00:54 PM UTC-7, Jameson wrote: > > one option would be to split deps/Makefile into N different deps/ABC.make > files (one for each dependency), so that each makefile could have a > dependency on itself > > otherwise, authors just need to be careful to introduce a makefile > dependency on the new build artifact whenever they add a patch file, or a > different output, etc. > > On Thu, Oct 30, 2014 at 1:46 AM, Tony Kelman <[email protected] > <javascript:>> wrote: > >> > Anyone have a dependency graph in mind? >> >> I think a dozen or so of us have the dependency graph more or less >> memorized. >> >> Since I'm pseudo-patching arpack via command-line -D flags, a stale copy >> of it seems to reuse cached autotools-generated copies of the makefiles. I >> think what we would effectively need to make rebuilds happen reliably would >> be some way of having any git pull that modifies the relevant flags or >> section of deps/Makefile also touch the corresponding configure scripts to >> make them rerun. And any time we add or modify a patch to a dependency, the >> only reliable ways I've found of forcing them to apply are either manually >> applying them, or cleaning out the existing sources which requires make -C >> deps distclean-xyz (and hence a re-downloading of the tarball and complete >> rebuild of that dependency). >> >> I'm sort of wishing we could do out-of-tree builds for some of this, to >> better separate sources from build objects. But some of the deps like >> openblas don't really support out-of-tree builds at all. Grand plan would >> be rewriting the thousands of lines of Makefile logic into CMake, which >> might handle all of this better with its caching mechanism. That might be a >> terrible idea and not work at all though, someone probably just has to try >> it and see whether it ends up better or worse. Cross-compilation (which >> only a few of us do very often) with CMake was... difficult... initially, >> but I eventually changed my mind on it and came to the conclusion that it >> just takes a really verbose invocation (or a toolchain file where you write >> down the long set of flags you need) to get working. >> >> >> >
