At Fri, 02 Jan 2015 14:17:02 -0500, Tony Garnock-Jones wrote: > On 01/02/2015 02:05 PM, Robby Findler wrote: > > I usually do something like that git pull, then 'make base' and then > > 'raco pkg update --all --auto' and then 'raco setup'. > > > > IIUC, these are in flux, however, so maybe there will be a different > > recommendation at some point. > > Would it make sense to have a top-level Makefile target "update" which > does those commands? It'd provide a stable name for them even as they > change. > > .PHONY: update > update: > git pull --ff-only > $(MAKE) base > raco pkg update --all --auto > raco setup > > ... or perhaps without the "git pull", even, depending on how nonuniform > people's git setups tend to be.
It feels wrong to me for a makefile to use `git pull`, which might change the makefile that contains that rule. Meanwhile, I keep thinking that `make update` should be just `make`. That is, a `make` that isn't the first `make` should produce the same result as if it had been the first `make` --- which implies downloading the latest versions of packages. I don't like that `make` would need network access. For that matter, I don't like that the initial `make` needs network access, but I see no way around the initial package download. Probably I should just get over `make` requiring the network in this context, and `make` should imply `raco pkg update` for consistency. Omitting some details, the sequence make base raco pkg update --all --auto --no-setup raco pkg install --no-setup --skip-installed --pkgs $(PKGS) raco setup seems right for the default `make` target. For the initial `make`, `raco pkg update` will be a no-op. For a subsequent `make`, assuming that `PKGS` hasn't changed, `raco pkg install` will be a no-op. Finally, there could be a new target that would be just the make base raco setup steps for rebuilding after local edits (i.e., for explicitly requesting something different than the current initial `make`). ____________________ Racket Users list: http://lists.racket-lang.org/users
