Open sakrejda opened 7 years ago
In theory, this would be fine (I think that this sort of approach is common in cmake, right?). It's a bit weird here because only some targets create files, and the object store is designed to opaque. But if it's useful and if it can be implemented without a great hassle that would be cool.
I can see that it would be complicated by trying to intercept file reads or file creations (e.g., if a function calls both read.csv
on a non-remake controlled file and png
making sure it reads and writes to different directories), but there might be a nice way or I might be overthinking it.
There is a slow process of tidying and refactoring the codebase that I need to spend some time on (but have had limited bandwidth for an extended period) and @krlmlr is working on at the moment. I'd rather we finish that process before significantly complicating the codebase. But if it's simple then that's not a big problem and a PR would be welcome.
Yes it's recommended with cmake and the build state/cache goes with the build directory. Even then it's easy to get a complex build that runs fine as your developing but has missing dependencies when you rebuild it from scratch.
I think it would be straightforward if you assume the object store goes with the build directory (you can't expect to do multiple builds cleanly at the same time against one object store). That's why I'm recommending having this work by setting up the out-of-tree build directory as something that remake::make() could run on independently.
I'm happy to wait until the code base gets cleaned up and then take a look at it.
I recall reading somewhere in the doc that out-of-tree builds are not supported but they are really helpful for keeping the tree clean. I've been doing out-of-tree builds manually by doing a fresh clone of the repo to run
remake::make()
but this could really be automatic. Probably could just automate this using whatever devtools relies on for svn/git/github functionality and allowing a calls like:The call could clone whatever the repo in that directory points to into the current directory and then continue with the usual
remake::make()
. Any reason that's a bad idea here? Any interest in a pull request?