mediagoblin-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

librejs support and autoconf bug


From: bill-auger
Subject: librejs support and autoconf bug
Date: Thu, 13 Oct 2022 14:05:21 -0400

re: https://issues.mediagoblin.org/ticket/5502

it appears that this work has already been done - librejs
accepts everything on the FSF's instance - i suspect that the
FSF sysadmins may have made the changes themselves - if so,
that would have been some years ago, and they may have offered
the changes upstream already - its not obvious which version
they are running; but probably whatever changes that instance
has, would go a long way toward supporting librejs upstream

https://media.libreplanet.org/

also, i have a work-around for the old autoconf bug - 
i encountered it years ago, when i first tried to upgrade
from 0.9.0; but i gave up then - recently, i decided to try again,
and made some progress

i found a bug report about it on the sr.ht forge - i must
say that it is rather inelegant and unhelpful to have multiple
bug trackers, each managing different bugs - thats why i am
sending email, rather than registering on both websites to
comment on the tickets

https://todo.sr.ht/~mediagoblin/mediagoblin/12
https://todo.sr.ht/~mediagoblin/mediagoblin/14

the immediate cause of that bug is that the generated configure
script is mangled/irregular - the specific problem reported
can be fixed after running autoconf, like so:

diff --git a/configure b/configure
index e0a4616..18eeef4 100755
--- a/configure
+++ b/configure
@@ -1931,8 +1931,7 @@ for as_dir in $PATH
 do
   IFS=$as_save_IFS
   case $as_dir in #(((
-    ''
-fi as_dir=./ ;;
+    '') as_dir=./ ;;
     */) ;;
     *) as_dir=$as_dir/ ;;
   esac
@@ -1970,7 +1969,7 @@ as_fn_error $? "--with-virtualenv given but virtualenv 
could not be found
 See \`config.log' for more details" "$LINENO" 5; }
 fi,
        VIRTUALENV=no
-)
+
 
 
 

_but_ ./configure still fails, because the the generated configure
script is more mangled than those obvious flaws - i stopped
trying to correct it any further, and looked for the underlying cause

i found that the `--with-virtualenv` handling in configure.ac
is the source of the corruption - i am able to compile by simply
deleting that section and replacing it with:

  AC_SUBST([VIRTUALENV], [no])

this is the working patch:

diff --git a/configure.ac b/configure.ac
index b9fdd6b..180b505 100644
--- a/configure.ac
+++ b/configure.ac
@@ -84,29 +84,7 @@ AS_IF([test "x$PYTHON" = xnone],
            [AC_MSG_FAILURE(
                [No acceptable python3 could be found])])
 
-dnl----
-dnl With the following set of macros, we implement an option 
-dnl "--with-virtualenv", which the user can pass to the configure 
-dnl script in order to install to a Virtualenv (AC_ARG_WITH). If the 
-dnl option is specified by the user, then we check if the program is
-dnl available, checking both for "virtualenv" and "virtualenv2" 
-dnl (AC_CHECK_PROGS)
-dnl----
-dnl
-# Support doing development in a virtualenv via the --with-virtualenv 
-# configure flag
-AC_ARG_WITH([virtualenv],
-       [AS_HELP_STRING([--without-virtualenv],
-                        [don't install a Python virtualenv for the user])],
-       [],
-       [with_virtualenv=yes])
-AS_IF([test "x$with_virtualenv" != xno],
-           AC_CHECK_PROGS([VIRTUALENV], [virtualenv virtualenv3 virtualenv2], 
[no])
-           AS_IF([test "x$VIRTUALENV" = xno],
-           [AC_MSG_FAILURE(
-               [--with-virtualenv given but virtualenv could not be found])]),
-       AC_SUBST([VIRTUALENV], [no]))
-AC_ARG_VAR([VIRTUALENV_FLAGS], [flags to pass to the virtualenv command])
+AC_SUBST([VIRTUALENV], [no])
 
 dnl----
 dnl If the program uses sphinx-build to build documentation, uncomment 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]