Hi! Alex Vong <[email protected]> skribis:
> On 06/10/2015, Ludovic Courtès <[email protected]> wrote: [...] >> It’s not uncommon, indeed. However, the details on how to bootstrap are >> not standard: Often ‘autoreconf -vfi’ will do, sometimes it’s >> ‘./bootstrap’, sometimes ‘./autogen.sh’, etc. >> >> Now the proposed build system could maybe try these variants one after >> the other. >> >> Also, the set of dependencies varies: sometimes it’s Autoconf, sometimes >> Autoconf+Automake, sometimes Autoconf+Automake+Libtool, etc. So I think >> the set of dependencies should be kept explicit–i.e., packages have to >> add stuff to ‘native-inputs’. >> >> Could you try to make this build system as a standalone commit, leaving >> out the build flags code for a separate discussion? >> >> The commit would add (guix build-system gnu-bootstrap) for instance (I >> call it this way because it bootstraps specifically the GNU build >> system, not CMake, etc.) and (guix build gnu-bootstrap-build-system). >> The latter would simply add one phase to ‘%standard-phases’. >> >> Does that make sense? >> > I think if the set of dependencies should be kept explicit, then it > seems the only thing we are left to abstract away is trying the > commands ``autoreconf -vfi'', ``./bootstrap'' and ``./autogen.sh''. > But I think the command is better left for the package maintainer to > decide since the bootstrap script may have unusual name. (I have seen > ``bootstrap.sh'' for instance.) My original though is to let the > package maintainer to pass in the bootstrap command string. However, > if it is the case, then gnu-bootstrap build-system isn't abstracting > anything at all. So I think I'll go back to the original solution of > adding a new phase and specifying autotools dependencies instead. Yeah, makes sense. A phase that guesses the command to run may still save a few lines here and there, but I agree that it may not be that beneficial overall. Thanks, Ludo’.
