[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Zack Weinberg]

Update of sr#110212 (group autoconf):

Priority: 1 - Blocked => 2 - Eventually 
Severity:  3 - Normal => 1 - Wish   


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

Re: [sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Nick Bowler]

On 2021-07-27, Eric Siegerman  wrote:
> Follow-up Comment #4, sr #110212 (project autoconf):
>
> 0 Edit _configure.ac_: In the _AC_INIT()_ call, change the first argument
> to
> the name you want to use for the subdirectory
> 0 Run _autoconf_ (perhaps indirectly, if the package provides an
> _autogen.sh_
> script or the like)
> 0 Run _configure_ with _--program-prefix_, _--program-suffix_, and/or
> _--program-transform-name_, as desired
> 0 Once the build is finished, do a test install into a scratch location
> using
> _DESTDIR=/where/ever_, and look it over to make sure all the pathnames that
> needed to be changed, were in fact changed.

Instead of all this hackery you can just set pkgdatadir when you build the
program, surely that's easier.  For example:

  % make clean
  % make pkgdatadir=/wherever/you/want install

This is expected to work with all build systems that follow the GNU
coding standards.

Cheers,
  Nick

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Eric Siegerman]

Follow-up Comment #4, sr #110212 (project autoconf):

Here's a workaround:

0 Edit _configure.ac_: In the _AC_INIT()_ call, change the first argument to
the name you want to use for the subdirectory
0 Run _autoconf_ (perhaps indirectly, if the package provides an _autogen.sh_
script or the like)
0 Run _configure_ with _--program-prefix_, _--program-suffix_, and/or
_--program-transform-name_, as desired
0 Once the build is finished, do a test install into a scratch location using
_DESTDIR=/where/ever_, and look it over to make sure all the pathnames that
needed to be changed, were in fact changed.

For my particular case (installing gpg1 in parallel with my distro's gpg2), I
appended "1" in both places:
  1. Made this change to _configure.ac_:
-AC_INIT([gnupg],[mym4_full_version], [https://bugs.gnupg.org])
+AC_INIT([gnupg1],[mym4_full_version], [https://bugs.gnupg.org])

  2. Called _configure --program-suffix=1_

My choice of a "1" suffix was informed by:
* the python convention, where the suffix is just the major version --
_python2_ vs _python3_
* a desire for consistency with the name of gpg's _gnupg1.info_ file (which is
hard-coded as such in Makefile.am; AFAICT, autoconf, configure, and make just
pass it through unmodified)

Note that this workaround caused some libexec files to be double-transformed,
e.g.:
$prefix/libexec/gnupg1/gpgkeys_curl1
 ^ ^
It probably also stuck that "1" in in various bits of documentation, etc.

But I was willing to live with those wrinkles.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Eric Siegerman]

Follow-up Comment #3, sr #110212 (project autoconf):

> Such a change first needs to be incorporated into the GNU Coding Standards.

Does it?  The relevant paragraph (from the July 1, 2021 version), says:

> The definition of ‘datadir’ is the same for all packages, so you should
install your data in a subdirectory thereof. Most packages install their data
under $(datadir)/package-name/.

To me, "Most packages install..." reads more like a recommendation than a firm
requirement -- and at that, an even weaker recommendation than the "should
install" in the first sentence.

Under that reading, modifying the ${datadir} subdirectory's name would _not_
be a violation of the standard as it's currently written.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Zack Weinberg]

Update of sr #110212 (project autoconf):

  Status:None => Postponed  

___

Follow-up Comment #2:

Savannah doesn't have a good way of tagging bugs that are blocked on some
external change, so I'm marking this one "postponed."

Regardless, Ross, if you want to push this forward, you should bring it up on
the bug-standards mailing list
.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Zack Weinberg]

Update of sr #110212 (project autoconf):

Priority:  5 - Normal => 1 - Later  


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Eric Blake]

Follow-up Comment #1, sr #110212 (project autoconf):

Such a change first needs to be incorporated into the GNU Coding Standards.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[sr #110212] Transform pkgdatadir using program-prefix and -suffix

[Ross Burton]

URL:
  

 Summary: Transform pkgdatadir using program-prefix and
-suffix
 Project: Autoconf
Submitted by: rossburton
Submitted on: Thu 19 Mar 2020 04:14:56 PM UTC
Category: None
Priority: 5 - Normal
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
Operating System: None

___

Details:

The main reason people will build autoconf with --program-prefix or
--program-suffix is most likely that they want to support multiple versions of
autoconf at the same time.

For example, binutils requires 2.69 exactly, but if 2.70 is released then
people will want to use that before binutils has switched and released.

Using --program-suffix=2.69 means that the binaries are installed as
/usr/bin/autoconf2.69, but pkgdatadir is still just /usr/share/autoconf. 
Everyone who wants parallel installable autoconf then has to fix this somehow
(either overwriting pkgdatadir, or fixing the paths after installation).

I suggest overwriting pkgdatadir to respect $program_prefix and
$program_suffix.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/