On Sat, Nov 03 2018, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> Although I'm on the fence with the approach in 1/5. Should this be a >> giant getopt switch statement like that in a helper script? >> >> An alternative would be to write out a shell file similar to >> GIT-BUILD-OPTIONS and source that from this thing. I don't know, >> what do you all think? > > Not really. Why do we iterate over these in a shell loop, rather > than having make to figure them out, just like we do when we "loop > over the source files and turn them into object files" without using > a shell loop? What's so special about enumerating the installation > targets and iterating over the enumeration to perform an action on > each of them? I think that is the first question we should be > asking before patch 1/5, which already assumes that it has been > decided that it must be done with a shell loop. > > I think "first install 'git' itself, and then make these > other things derived from it" should let $(MAKE) install > things in parallel just like it can naturally do many things > in parallel, and the dependency rule to do so should not be > so bad, I suspect. > > This is a tangent, but I have long been wishing that somebody would > notice that output during install and (dist)clean without V=1 is so > different from the normal targets and do something about it, and > hoped that that somebody finally turned out to be you doing so in > this series X-<. I'm all for this, but don't have enough Make skills to make it happen. Can you or someone else post a WIP patch showing how to do this? What would the targets look like? Something that's a build target for the target file in the installation directory, so e.g. if you ran "all install" and had modified just one file (and no recursive rebuilds) you'd install just that one file? Early on in the "install" target we install many of these programs, and then some of these for-loops re-install on top of them. Actually now that I think of this this is one of the reasons for the 2>/dev/null probably, i.e. run "install" twice and you don't want to get errors. Anyway, regardless of how the for-loop looks like (shell or make-powered) I split this up because it was getting really hard to maintain the *inner* part of those loops. I.e. needing to specially quote everything, end lines with \ etc. But reading on... >> I'd like to say it's ready, but I've spotted some fallout: > > I still have not recovered from the trauma I suffered post 1.6.0 > era, so I would rather *not* engage in a long discussion like this > one (it is a long thread; reserve a solid hour to read it through if > you are interested), > > https://public-inbox.org/git/alpine.LFD.1.10.0808261435470.3363@xxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > which would be needed to defend the choice, if we decide to omit > installing the git-foo on disk in a released version. Thanks. I'll read that later. > I personally have no objection to offer a knob that can e used to > force installation of symlinks without falling back to other > methods. I think it would be ideal to do so without special casing > symbolic links---rather, it would be ideal if it were a single knob > INSTALL_GIT_FOO_METHOD=(symlinks|hardlinks|copies) that says "I want > them to be installed as (symlinks|hardlinks|copies), no fallbacks". ... If you're happy to accept a patch that rips out this whole conditional fallback logic and just makes it an if/elsif/elsif for symlink/hardlink/copy this makes things a lot easier. >> Ævar Arnfjörð Bjarmason (5): >> Makefile: move long inline shell loops in "install" into helper >> Makefile: conform some of the code to our coding standards >> Makefile: stop hiding failures during "install" >> Makefile: add NO_INSTALL_SYMLINKS_FALLBACK switch >> Makefile: Add a NO_INSTALL_BUILTIN_EXECDIR_ALIASES flag >> >> Makefile | 65 +++++++++++-------------- >> install_programs | 124 +++++++++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 151 insertions(+), 38 deletions(-) >> create mode 100755 install_programs
