4.0b22 doesn't seem to be respecting --prefix= at install. I looked through the makefile and notice that there is a PACKAGE_SUBDIR (/ 4.0b22) appended to prefix. Is this supposed to happen by default? I don't recall previous Gambit betas doing this, and am not sure I want to add another set of directories to PATH et al. Is there a way to work around this?
uname -a && machine Darwin kyoto 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc ppc970
Afficher les réponses par date
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 5-Apr-07, at 7:51 PM, Robert D. Skeels wrote:
4.0b22 doesn't seem to be respecting --prefix= at install. I looked through the makefile and notice that there is a PACKAGE_SUBDIR (/ 4.0b22) appended to prefix. Is this supposed to happen by default? I don't recall previous Gambit betas doing this, and am not sure I want to add another set of directories to PATH et al. Is there a way to work around this?
uname -a && machine Darwin kyoto 8.9.0 Darwin Kernel Version 8.9.0: Thu Feb 22 20:54:07 PST 2007; root:xnu-792.17.14~1/RELEASE_PPC Power Macintosh powerpc ppc970
The new directory structure, which is explained on the first page of the Gambit manual, has been in use for several betas. If you are installing version VERSION with a prefix of PREFIX, the following directories are created to store the executable files, libraries, etc:
PREFIX/VERSION <- contains bin/, lib/, include/, etc PREFIX/current <- symbolic link to PREFIX/VERSION
This organization allows multiple versions of Gambit to coexist in the PREFIX directory. By putting "PREFIX/current/bin" in your PATH, you will automatically have access to the latest version of Gambit installed. You don't have to change your PATH when a new version is installed. But if you wish to execute a specific version of Gambit, you can specify that in the path, i.e. PREFIX/4.0b20/bin/gsi .
Marc
On 4/6/07, Robert D. Skeels rdsathene@sbcglobal.net wrote:
4.0b22 doesn't seem to be respecting --prefix= at install. I looked through the makefile and notice that there is a PACKAGE_SUBDIR (/ 4.0b22) appended to prefix.
Indeed. I noticed the same thing last week when I created the MacPorts configuration for 4.0b20 [1].
Is there a way to work around this?
I worked around it with lots of regex substitutions for each makefile in the distribution. Not pretty, but does the job. You could use the `sed' command to manually perform the substitutions in a similar manner as done in the MacPorts portfile [2].
[1] http://trac.macports.org/projects/macports/ticket/11688 [2] http://trac.macports.org/projects/macports/attachment/ticket/11688/Portfile
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 5-Apr-07, at 9:23 PM, Arto Bendiken wrote:
On 4/6/07, Robert D. Skeels rdsathene@sbcglobal.net wrote:
4.0b22 doesn't seem to be respecting --prefix= at install. I looked through the makefile and notice that there is a PACKAGE_SUBDIR (/ 4.0b22) appended to prefix.
Indeed. I noticed the same thing last week when I created the MacPorts configuration for 4.0b20 [1].
Is there a way to work around this?
I worked around it with lots of regex substitutions for each makefile in the distribution. Not pretty, but does the job. You could use the `sed' command to manually perform the substitutions in a similar manner as done in the MacPorts portfile [2].
If you really want to get rid of the "VERSION" subdirectory, the easiest approach is to change "configure" (and/or "configure.ac"). You have to replace
PACKAGE_SUBDIR="/4.0b22"
with
PACKAGE_SUBDIR=""
Then run ./configure and make.
Marc
On 4/6/07, Marc Feeley feeley@iro.umontreal.ca wrote:
If you really want to get rid of the "VERSION" subdirectory, the easiest approach is to change "configure" (and/or "configure.ac"). You have to replace
PACKAGE_SUBDIR="/4.0b22"
with
PACKAGE_SUBDIR=""
Then run ./configure and make.
Yes, I did that, too - but it's not sufficient, in itself, to ensure a clean MacPorts installation. Please have a look at the portfile:
http://trac.macports.org/projects/macports/attachment/ticket/11688/Portfile
There are at least two further issues:
a) Any explicit --infodir, --libdir, etc. directives to ./configure are not observed in the source makefiles.
b) After compilation, MacPorts stages the installation into a temporary destroot directory before making a binary tarball and installing into the real target. Because the installation paths in Gambit's source makefiles aren't prefixed by $(DESTDIR), the destroot stage actually prematurely installs all the files into the final target (in the case of MacPorts, into /opt/local/), leaving the destroot empty and causing the package build to fail.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 6-Apr-07, at 6:05 AM, Arto Bendiken wrote:
Yes, I did that, too - but it's not sufficient, in itself, to ensure a clean MacPorts installation. Please have a look at the portfile:
http://trac.macports.org/projects/macports/attachment/ticket/11688/ Portfile
There are at least two further issues:
a) Any explicit --infodir, --libdir, etc. directives to ./configure are not observed in the source makefiles.
b) After compilation, MacPorts stages the installation into a temporary destroot directory before making a binary tarball and installing into the real target. Because the installation paths in Gambit's source makefiles aren't prefixed by $(DESTDIR), the destroot stage actually prematurely installs all the files into the final target (in the case of MacPorts, into /opt/local/), leaving the destroot empty and causing the package build to fail.
OK. I will look into this. I will also add a configure option to set the PACKAGE_SUBDIR to "" when calling ./configure .
Marc
-
Arto Bendiken -
Marc Feeley -
Robert D. Skeels