[pacman-dev] [PATCH 1/3] contrib/*: Hardcode program names
Add a read-only variable "$myname" to every contrib script and hardcode
program names instead of relying on "$0". The variable name "$myname"
was chosen because it is already used in pacman and because we use
"$myver" to specify the program version in the official scripts.
Signed-off-by: Lukas Fleischer
Be more semantically accurate and avoid accidental overwriting of some
configuration variables that are considered to be constant.
Signed-off-by: Lukas Fleischer
Add "--help"/"-h" and "--version"/"-V" support to all contrib scripts.
Also, update scripts that used "-v" as a short option for "--version"
and use "-V" for the sake of consistency.
Additionally:
* Move version and usage messages to separate convenience functions in
all scripts.
* Add a workaround to paccache to support "--help" and "--version". This
should be replaced by a proper POSIX-compliant command line parser
that supports long options in a future patch.
* Add a "$myver" variable to all scripts and use it whenever we refer to
the program version (e.g. in version messages). Also, use the pacman
version number everywhere instead of using a different versioning
scheme for each contrib script. This is achieved by adding a
"PACKAGE_VERSION" placeholder that is replaced by sed(1) when the
script is built.
* Ensure we always return with exit status 0 if "--help" is used and
return with exit status 1 if we display the usage message due to
invalid arguments.
* Add "AUTOMAKE_OPTIONS = std-options" and add all scripts to
"bin_SCRIPTS" to make `make installcheck` check that installed scripts
actually support the "--help" and "--version" options.
Signed-off-by: Lukas Fleischer
On Tue, Dec 6, 2011 at 3:29 PM, Lukas Fleischer
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? -Dan [1] http://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/pacman-contrib&id=375c3222509ba830de48a3365ceb8ae72d491a7c
On Tue, Dec 06, 2011 at 04:38:41PM -0600, Dan McGee wrote:
On Tue, Dec 6, 2011 at 3:29 PM, Lukas Fleischer
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/"...
-Dan
On Tue, Dec 6, 2011 at 4:58 PM, Lukas Fleischer
On Tue, Dec 06, 2011 at 04:38:41PM -0600, Dan McGee wrote:
On Tue, Dec 6, 2011 at 3:29 PM, Lukas Fleischer
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. -Dan
On Tue, Dec 06, 2011 at 05:05:20PM -0600, Dan McGee wrote:
On Tue, Dec 6, 2011 at 4:58 PM, Lukas Fleischer
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
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...
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
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
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. Allan
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
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
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
This implies following changes:
* contrib scripts can be built and installed easily by running make(1)
in "contrib/". This removes the need to pick all contrib scripts
manually when packaging pacman-contrib.
* contrib scripts will no longer be built when running make(1) in the
top level source directory. This seems like the most natural approach.
We install those separately and should act the same when building
stuff.
Signed-off-by: Lukas Fleischer
Add "--help"/"-h" and "--version"/"-V" support to all contrib scripts.
Also, update scripts that used "-v" as a short option for "--version"
and use "-V" for the sake of consistency.
Additionally:
* Move version and usage messages to separate convenience functions in
all scripts.
* Add a workaround to paccache to support "--help" and "--version". This
should be replaced by a proper POSIX-compliant command line parser
that supports long options in a future patch.
* Add a "$myver" variable to all scripts and use it whenever we refer to
the program version (e.g. in version messages). Also, use the pacman
version number everywhere instead of using a different versioning
scheme for each contrib script. This is achieved by adding a
"PACKAGE_VERSION" placeholder that is replaced by sed(1) when the
script is built.
* Ensure we always return with exit status 0 if "--help" is used and
return with exit status 1 if we display the usage message due to
invalid arguments.
* Add "AUTOMAKE_OPTIONS = std-options" and add all scripts to
"bin_SCRIPTS" to make `make installcheck` check that installed scripts
actually support the "--help" and "--version" options.
Signed-off-by: Lukas Fleischer
On 13/12/11 07:36, Lukas Fleischer wrote:
This implies following changes:
* contrib scripts can be built and installed easily by running make(1) in "contrib/". This removes the need to pick all contrib scripts manually when packaging pacman-contrib.
* contrib scripts will no longer be built when running make(1) in the top level source directory. This seems like the most natural approach. We install those separately and should act the same when building stuff.
Signed-off-by: Lukas Fleischer
Looks good to me Allan
participants (3)
-
Allan McRae
-
Dan McGee
-
Lukas Fleischer