[pacman-dev] [PATCH 3/3] contrib/*: Support the "--help" and "--version" options

Lukas Fleischer archlinux at cryptocrack.de
Wed Dec 7 11:49:24 EST 2011


On Tue, Dec 06, 2011 at 05:05:20PM -0600, Dan McGee wrote:
> On Tue, Dec 6, 2011 at 4:58 PM, Lukas Fleischer
> <archlinux at cryptocrack.de> 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
> >> <archlinux at cryptocrack.de> 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"!).

* "I am used to run `make` in the top level source directory to build
  everything." might be a valid reason for you but isn't a valid point
  for me. We should do things right and look at things from a user
  perspective, laziness doesn't count :p

* This makes the pacman-contrib PKGBUILD damn easy (just cd(1) to the
  "contrib/" directory instead of the pacman top level source directory
  and run the usual `make` in build(), `make install` in package()).

Just my two cents...


More information about the pacman-dev mailing list