Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#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)

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.

comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

Cc Me!

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

     
    138138                                AC_MSG_ERROR([Don't know how to extract tarball $mp_tarball])
    139139                                ;;
    140140                esac
     141    # bzip2 uses the BZIP2 environment variable as an argument. Clear it out during execution.
     142    BZIP2_SAVE=$BZIP2
     143    BZIP2=
    141144                (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
    142146        fi
    143147        if ! test -d "$ac_dir"; then
    144148                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

     
    133133                                        AC_MSG_ERROR([bzip2 not found])
    134134                                fi
    135135                                mp_tarball_extract_cmd="$BZIP2"
     136                                export -n BZIP2
    136137                                ;;
    137138                        *)
    138139                                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: newclosed

This has already been fixed in r118736.

comment:9 Changed 11 years ago by eborisch (Eric A. Borisch)

Resolution: fixed
Status: closedreopened

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:11 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

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

     
    9696        $1=$(AS_ECHO([$2]) | sed -E 's/^--?([[^=]]+)=.*$/\1/')dnl
    9797])
    9898
     99dnl Similar to AC_ARG_VAR, but implemented with --with-pkg=PATH for PKG.
     100dnl
     101dnl Parameters: Similar to AC_ARG_VAR ($2 gets some boiler plate around it)
     102AC_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
    99109dnl Configure a project contained in a .tar.gz, .tgz or .tar.bz2 tarball,
    100110dnl extracting it previously, if necessary. Different from AC_CONFIG_SUBDIRS
    101111dnl (on which this macro is based), you can pass parameters to the
     
    138148                                AC_MSG_ERROR([Don't know how to extract tarball $mp_tarball])
    139149                                ;;
    140150                esac
    141                 (cd "$mp_tarball_vendordir"; "$mp_tarball_extract_cmd" -dc "$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]))
    142152        fi
    143153        if ! test -d "$ac_dir"; then
    144154                AC_MSG_ERROR([tarball $mp_tarball did not extract to $ac_dir])
  • configure.ac

     
    101101AC_PROG_MAKE_SET
    102102AC_PROG_OBJC([clang cc gcc])
    103103
     104# Check for user-supplied paths before searching
     105MP_TOOL_PATH(BSDMAKE, [bsdmake/pmake])
     106MP_TOOL_PATH(BZIP2, [bzip2])
     107MP_TOOL_PATH(CVS, [cvs])
     108MP_TOOL_PATH(GNUMAKE, [gnumake])
     109MP_TOOL_PATH(GNUTAR, [gnutar])
     110MP_TOOL_PATH(LZMA, [lzma])
     111MP_TOOL_PATH(MAKE, [make])
     112MP_TOOL_PATH(MTREE, [mtree])
     113MP_TOOL_PATH(OPEN, [open])
     114MP_TOOL_PATH(OPENSSL, [openssl])
     115MP_TOOL_PATH(RSYNC, [rsync])
     116MP_TOOL_PATH(SED, [sed])
     117MP_TOOL_PATH(SVN, [svn])
     118MP_TOOL_PATH(SWIG, [swig])
     119MP_TOOL_PATH(TAR, [tar])
     120MP_TOOL_PATH(XAR, [xar])
     121MP_TOOL_PATH(XZ, [xz])
     122
     123# Search for tool paths. Any set above (via --with-pkg=PATH) are retained
    104124AC_PATH_PROGS(BSDMAKE, [bsdmake pmake], [])
    105125AC_PATH_PROG(BZIP2, [bzip2], [])
    106126AC_PATH_PROG(BZR, [bzr], [])
     
    149169
    150170AC_CHECK_PROG(HAVE_LAUNCHD, [launchd], [yes], [], [/sbin])
    151171
    152 # Define some precious variables allowing user to override PATH for some programs
    153 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])
    170172
    171173if test "x$MTREE" = "x"; then
    172174    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: reopenedclosed

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.

Note: See TracTickets for help on using tickets.