On Sat, Dec 10, 2011 at 09:28:03PM +1000, Allan McRae wrote: > On 08/12/11 02:49, Lukas Fleischer wrote: > > On Tue, Dec 06, 2011 at 05:05:20PM -0600, Dan McGee wrote: > >> On Tue, Dec 6, 2011 at 4:58 PM, Lukas Fleischer > >> <[email protected]> wrote: > >>> On Tue, Dec 06, 2011 at 04:38:41PM -0600, Dan McGee wrote: > >>>> On Tue, Dec 6, 2011 at 3:29 PM, Lukas Fleischer > >>>> <[email protected]> wrote: > >>>>> Can some autotools wizard please check if I broke anything here? `make > >>>>> distcheck` still looks good to me but I'm not 100% sure what I broke by > >>>>> adding all scripts to "bin_SCRIPTS" :) > >>>> > >>>> Before: `make install` does not install contrib/. > >>>> After: `make install` installs contrib/. So probably not what we want, > >>>> at least recursively or by default. It would be nice that if you were > >>>> actually in contrib, `make install` would do what one expected (and > >>>> kill the ugly hardcoding of each script needed to currently install > >>>> [1]). Autotools probably makes a setup like this a bitch though. > >>>> Thoughts from anyone else? > >>> > >>> How about removing "contrib" from "SUBDIRS" in our main Makefile.am and > >>> adding something like "DIST_SUBDIRS = $(SUBDIRS) contrib"? This way, > >>> contrib scripts won't be installed when running `make install` in the > >>> top level source directory but can be easily installed by running `make > >>> install` in "contrib/"... > >> > >> The problem there is it completely stops make from descending in > >> there, and as I've seen many times before (namely with docs), it gets > >> ugly when I have to package it. I think you'd be out of luck because > >> your Makefile wouldn't even be generated in there, and thus *.in never > >> gets converted to the scripts and other files. > > > > It doesn't completely stop make from descending in there. As discussed > > on IRC, directories listed in "DIST_SUBDIRS" will still be honored when > > running `make dist`. The only difference is that we would have to run > > `make` and `make install` separately in "contrib/". This makes sense to > > me because: > > > > * I consider contrib scripts a sub-project of (and not part of) pacman. > > If you say that they actually do belong to pacman, there should be a > > possibility to install contrib scripts when using make(1) (e.g. by > > introducing a configure option like "--with-contrib"). This seems very > > natural, at least. > > > > Given that we probably do not want to install contrib scripts together > > with pacman and prefer separate install trees/procedures, it doesn't > > make any sense to build contrib scripts in the same procedure we use > > for building pacman, also. Basically, saying that you will have to > > run `make install` separately since it's a different sub-project but > > build it when building the main project feels a bit obscure... > > > > tl;dr: To me, only one of these options make sense: > > > > - Make contrib scripts optional but build *and* install them together > > with pacman (that means "introduce a configure option"). > > > > - Use a different build *and* install procedure for contrib scripts > > (that means "use DIST_SUBDIRS"!). > > This option makes sense to me (and I have seen that sort of idea used > elsewhere). > > One query about this approach... Will running ./configure still > generate the Makefile in contrib/ when doing this? Because having to > maintain a separate configure script that does the same substitutions as > the main one would be annoying.
Yeah, it will still generate the Makefile. I tested this running `./autoclean.sh; ./autogen.sh; ./configure`. > > Allan
