#43204 closed defect (fixed)
Change BZIP2 variable name for configure script
Reported by: | eborisch (Eric A. Borisch) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.2.1 |
Keywords: | Cc: | neverpanic (Clemens Lang), ryandesign (Ryan Carsten Schmidt), cooljeanius (Eric Gallager) | |
Port: |
Description
As the configure script now calls bzip2 directly, having BZIP2 set during configure (as required to explicitly set the BZIP2 path for MP to use) causes bzip2 (when run by configure) to fail, as bzip2 uses $BZIP2 as an argument: https://www.opensource.apple.com/source/bzip2/bzip2-16.5/bzip2/bzip2.txt )
I set BZIP2 to call my own installed pbzip2 (because it makes anything locally compressed and then extracted -- for example during port activations -- go faster.) This actually works because pbzip2 doesn't use BZIP2. But setting the BZIP2 path via ./configure BZIP2=/usr/bin/bzip2
or BZIP2=/usr/bin/bzip2 ./configure
will fail on a fresh copy (or distclean-ed) of base.
Change History (14)
comment:1 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
comment:3 Changed 11 years ago by neverpanic (Clemens Lang)
If we did that for all our incovations of AC_ARG_VAR
that would add another 17 possible arguments. I don't think this is the way to go.
The list would be:
- BSDMAKE
- BZIP2
- CVS
- GNUMAKE
- GNUTAR
- LZMA
- MAKE
- MTREE
- OPEN
- OPENSSL
- RSYNC
- SED
- SVN
- SWIG
- TAR
- XAR
- XZ
comment:4 Changed 11 years ago by eborisch (Eric A. Borisch)
Most applications (wild speculation; haven't run into others, I'm sure there are some out there) don't use an environment variable sharing their name as an argument.
Perhaps this tweak aclocal.m4 is lower impact:
-
aclocal.m4
138 138 AC_MSG_ERROR([Don't know how to extract tarball $mp_tarball]) 139 139 ;; 140 140 esac 141 # bzip2 uses the BZIP2 environment variable as an argument. Clear it out during execution. 142 BZIP2_SAVE=$BZIP2 143 BZIP2= 141 144 (cd "$mp_tarball_vendordir"; "$mp_tarball_extract_cmd" -d < "$ac_abs_confdir/$mp_tarball" | tar xf - || AC_MSG_ERROR([failed to extract $mp_tarball])) 145 BZIP2=$BZIP2_SAVE 142 146 fi 143 147 if ! test -d "$ac_dir"; then 144 148 AC_MSG_ERROR([tarball $mp_tarball did not extract to $ac_dir])
The only side effect here is an extra BZIP2_SAVE variable after it has been evauated.
comment:5 Changed 11 years ago by eborisch (Eric A. Borisch)
Also related: there is some discussion going on in the users list -- I didn't start it ;) -- about using something other than vanilla bzip2. https://lists.macosforge.org/pipermail/macports-users/2014-April/035115.html
comment:6 Changed 11 years ago by neverpanic (Clemens Lang)
I'd rather go with:
-
aclocal.m4
133 133 AC_MSG_ERROR([bzip2 not found]) 134 134 fi 135 135 mp_tarball_extract_cmd="$BZIP2" 136 export -n BZIP2 136 137 ;; 137 138 *) 138 139 AC_MSG_ERROR([Don't know how to extract tarball $mp_tarball])
which should get the job done aswell.
comment:7 Changed 11 years ago by eborisch (Eric A. Borisch)
Works for me. I can commit this up, if you like.
comment:8 Changed 11 years ago by neverpanic (Clemens Lang)
Resolution: | → fixed |
---|---|
Status: | new → closed |
This has already been fixed in r118736.
comment:9 Changed 11 years ago by eborisch (Eric A. Borisch)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
That doesn't actually fix it -- it still fails on the first (taken from BZIP2 env) argument and then decompresses the second. It still fails when used with lbzip2 (which emulates bzip2's usage of the BZIP2 variable) which bails when asked to decompress a non-bzip2 file.
I would suggest revert r118736 (or don't -- either way works) and use the export -n BZIP2
change above. (Potentially followed by a re-export, if you really want to limit the impact of the change.)
make distclean BZIP2=/usr/bin/bzip2 ./configure [...] configure: === extracting vendor/tclx8.4.1.tar.bz2 bzip2: /usr/bin/bzip2 is not a bzip2 file.
comment:10 Changed 11 years ago by neverpanic (Clemens Lang)
Yeah, I thought the "fix" wasn't particularly robust, so feel free to add the export -n BZIP2
line as well, probably as (export -n BZIP2) >/dev/null 2>&1 && export -n BZIP2
to avoid errors in shells that don't support export -n
.
Don't forget to run ./regen.sh
after changing aclocal.m4
.
comment:12 Changed 11 years ago by eborisch (Eric A. Borisch)
Going through it, I think I prefer the configure arguments for paths. I'm not convinced that 17 extra arguments is any more or less complex than 17 environment variables. Given that the ENVs get exported to anything running underneath, the pure arguments are in a sense less complex.
Here's a patch that will (after running through ./regen.sh) update configure to have --with-tool=path arguments. This fixes the exported BZIP2 variable tripping up bzip2 issue, as well.
This patch also backs-out r118736; this could be done separately for tracking, of course. (Or not at all, either works, I was just trying to minimize total changes vs -r old for this ticket.)
Note that anyone performing TOOL=PATH ./configure
will still get (essentially) the previous behavior -- so this shouldn't break anyone's custom build that was relying on setting the tool paths in environment variables. This occurs because $with_tool will be unset, and AC_PATH_PROG(TOOL, ...) will be overridden if the variable TOOL is set. (They may not now be marked as precious, but that's another level of autoconf grokking that I'm not at...)
-
aclocal.m4
96 96 $1=$(AS_ECHO([$2]) | sed -E 's/^--?([[^=]]+)=.*$/\1/')dnl 97 97 ]) 98 98 99 dnl Similar to AC_ARG_VAR, but implemented with --with-pkg=PATH for PKG. 100 dnl 101 dnl Parameters: Similar to AC_ARG_VAR ($2 gets some boiler plate around it) 102 AC_DEFUN([MP_TOOL_PATH], [dnl 103 AC_ARG_WITH([m4_tolower($1)], [AS_HELP_STRING([--with-m4_tolower($1)=PATH], 104 [Path to alternate $2 command])],dnl 105 [$1=$withval],dnl 106 [])dnl 107 ]) 108 99 109 dnl Configure a project contained in a .tar.gz, .tgz or .tar.bz2 tarball, 100 110 dnl extracting it previously, if necessary. Different from AC_CONFIG_SUBDIRS 101 111 dnl (on which this macro is based), you can pass parameters to the … … 138 148 AC_MSG_ERROR([Don't know how to extract tarball $mp_tarball]) 139 149 ;; 140 150 esac 141 (cd "$mp_tarball_vendordir"; "$mp_tarball_extract_cmd" -d c"$ac_abs_confdir/$mp_tarball" | tar xf - || AC_MSG_ERROR([failed to extract $mp_tarball]))151 (cd "$mp_tarball_vendordir"; "$mp_tarball_extract_cmd" -d < "$ac_abs_confdir/$mp_tarball" | tar xf - || AC_MSG_ERROR([failed to extract $mp_tarball])) 142 152 fi 143 153 if ! test -d "$ac_dir"; then 144 154 AC_MSG_ERROR([tarball $mp_tarball did not extract to $ac_dir]) -
configure.ac
101 101 AC_PROG_MAKE_SET 102 102 AC_PROG_OBJC([clang cc gcc]) 103 103 104 # Check for user-supplied paths before searching 105 MP_TOOL_PATH(BSDMAKE, [bsdmake/pmake]) 106 MP_TOOL_PATH(BZIP2, [bzip2]) 107 MP_TOOL_PATH(CVS, [cvs]) 108 MP_TOOL_PATH(GNUMAKE, [gnumake]) 109 MP_TOOL_PATH(GNUTAR, [gnutar]) 110 MP_TOOL_PATH(LZMA, [lzma]) 111 MP_TOOL_PATH(MAKE, [make]) 112 MP_TOOL_PATH(MTREE, [mtree]) 113 MP_TOOL_PATH(OPEN, [open]) 114 MP_TOOL_PATH(OPENSSL, [openssl]) 115 MP_TOOL_PATH(RSYNC, [rsync]) 116 MP_TOOL_PATH(SED, [sed]) 117 MP_TOOL_PATH(SVN, [svn]) 118 MP_TOOL_PATH(SWIG, [swig]) 119 MP_TOOL_PATH(TAR, [tar]) 120 MP_TOOL_PATH(XAR, [xar]) 121 MP_TOOL_PATH(XZ, [xz]) 122 123 # Search for tool paths. Any set above (via --with-pkg=PATH) are retained 104 124 AC_PATH_PROGS(BSDMAKE, [bsdmake pmake], []) 105 125 AC_PATH_PROG(BZIP2, [bzip2], []) 106 126 AC_PATH_PROG(BZR, [bzr], []) … … 149 169 150 170 AC_CHECK_PROG(HAVE_LAUNCHD, [launchd], [yes], [], [/sbin]) 151 171 152 # Define some precious variables allowing user to override PATH for some programs153 AC_ARG_VAR(BSDMAKE, [path to bsdmake/pmake command])154 AC_ARG_VAR(BZIP2, [path to bzip2 command])155 AC_ARG_VAR(CVS, [path to cvs command])156 AC_ARG_VAR(GNUMAKE, [path to gnumake command])157 AC_ARG_VAR(GNUTAR, [path to gnutar command])158 AC_ARG_VAR(LZMA, [path to lzma command])159 AC_ARG_VAR(MAKE, [path to make command])160 AC_ARG_VAR(MTREE, [path to mtree command])161 AC_ARG_VAR(OPEN, [path to open command])162 AC_ARG_VAR(OPENSSL, [path to openssl command])163 AC_ARG_VAR(RSYNC, [path to rsync command])164 AC_ARG_VAR(SED, [path to sed command])165 AC_ARG_VAR(SVN, [path to svn command])166 AC_ARG_VAR(SWIG, [path to swig command])167 AC_ARG_VAR(TAR, [path to tar command])168 AC_ARG_VAR(XAR, [path to xar command])169 AC_ARG_VAR(XZ, [path to xz command])170 172 171 173 if test "x$MTREE" = "x"; then 172 174 AC_MSG_ERROR([mtree not found])
Snippet of ./configure --help
output now:
Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-bsdmake=PATH Path to alternate bsdmake/pmake command --with-bzip2=PATH Path to alternate bzip2 command --with-cvs=PATH Path to alternate cvs command
comment:13 Changed 11 years ago by eborisch (Eric A. Borisch)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Committed in r119421:119423.
comment:14 Changed 10 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Note that anyone performing TOOL=PATH ./configure will still get (essentially) the previous behavior -- so this shouldn't break anyone's custom build that was relying on setting the tool paths in environment variables. This occurs because $with_tool will be unset, and AC_PATH_PROG(TOOL, ...) will be overridden if the variable TOOL is set. (They may not now be marked as precious, but that's another level of autoconf grokking that I'm not at...)
Oh, so THIS is why my build script hasn't been working right for months...
This actually doesn't do the same thing for people setting environment variables with AC_ARG_VAR. AC_ARG_VAR results in the value being cached whereas this does not.
For example, I check ac_cv_env_BZIP2_value and others to see what base was built with when determining if I need to rebuild base. This new approach never saves those in the autoconf cache, so I end up rebuilding base every time I do an update.
It would be more customary if the path to the bzip2 program could be specified by a configure argument (e.g.
--with-bzip2=...
) instead of an environment variable.