lmi
[Top][All Lists]
Advanced

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

Re: [lmi] Concinnity check and hardcoded paths


From: Greg Chicares
Subject: Re: [lmi] Concinnity check and hardcoded paths
Date: Sat, 17 Oct 2020 15:05:00 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 2020-10-16 22:31, Vadim Zeitlin wrote:
> On Tue, 13 Oct 2020 01:11:44 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> The widespread assumption that 'prefix="/opt/lmi"' is probably harder
> GC> to alleviate (although I think we may be getting close),
> 
>  I am not sure if you want to deal with this at this time, but if it could
> be helpful, I can easily make a hopefully exhaustive list of places that
> would need to be changed to solve it. But I suspect you have more important
> things to do right now, so I won't sent such list unsolicited.

You're welcome to send it whenever you like. I probably won't be
ready to look at it before December at the earliest.

> GC> Anyway, I think I should make this change everywhere:
> GC> 
> GC>   . ./lmi_setup_inc.sh
> GC> + # shellcheck disable=SC1091
> GC>   . /tmp/schroot_env
> 
>  Thanks for making it, this does help with not having this particular file.
> In the interest of, dare I say it, concinnity, I wonder if this warning
> should also be suppressed for the line
> 
>       . /opt/lmi/src/lmi/set_toolchain.sh
> 
> in lmi_setup_43.sh as this would solve another similar problem. Of course,

Done.

I also looked for anything similar:
  $git grep '\. \.' 
  $git grep '\. \/'
but only this one seemed to need changing.

> IMHO a better solution would be to just use ". ./set_toolchain.sh" here,
> but this might be taking us into the unsolicited territory, as mentioned
> above...

If you're at that line in vim and do '?cd', you'll see
  cd proprietary || { printf 'failed: cd\n'; exit 3; }
about twenty lines earlier--so './' wouldn't find this script.

'transume_toolchain.sh' also sources another script. I've been
contemplating several changes there, but can't persuade myself
that any of them deserve to be committed, so let me show you
what I've stashed aside and ask what you think:

--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--
diff --git a/transume_toolchain.sh b/transume_toolchain.sh
index 672bda12..c61218af 100755
--- a/transume_toolchain.sh
+++ b/transume_toolchain.sh
@@ -23,10 +23,41 @@
 
 # See 'GNUmakefile' for suggested use.
 
-. ./set_toolchain.sh
+# The script here sourced, 'set_toolchain.sh', should reside in the
+# same directory as this script, i.e.,
+#   "$(dirname "$(readlink -f "$0")")"
+# It's hard to imagine that it wouldn't, but should the possibility
+# be guarded against? Is the dirname-readlink obscurity warranted?
+#
+# shellcheck disable=SC1090
+. "$(dirname "$(readlink -f "$0")")"/set_toolchain.sh
 
-printf '%s\n' "export LMI_COMPILER := $LMI_COMPILER"
-printf '%s\n' "export LMI_TRIPLET  := $LMI_TRIPLET"
-printf '%s\n' "export PATH         := $PATH"
-printf '%s\n' "export WINEPATH     := $WINEPATH"
-printf '%s\n' "export PERFORM      := $PERFORM"
+# Should $LD_LIBRARY_PATH be treated the same as $WINEPATH both
+# here and in 'GNUMakefile'?
+
+# Is it important to avoid writing
+#   export FOO=bar
+# tersely on a single line, which POSIX doesn't strictly support?
+
+printf '%s\n' "LMI_COMPILER=$LMI_COMPILER"
+printf '%s\n' "LMI_TRIPLET=$LMI_TRIPLET"
+printf '%s\n' "PATH=$PATH"
+printf '%s\n' "WINEPATH=$WINEPATH"
+printf '%s\n' "PERFORM=$PERFORM"
+
+printf '%s\n' "export LMI_COMPILER"
+printf '%s\n' "export LMI_TRIPLET"
+printf '%s\n' "export PATH"
+printf '%s\n' "export WINEPATH"
+printf '%s\n' "export PERFORM"
+
+# More compact, but perhaps less scrutable:
+#
+# for z in LMI_COMPILER LMI_TRIPLET PATH WINEPATH PERFORM
+#   do
+#     # Avoid SC2154 with empty assignment:
+#     value=
+#     eval "value=\${$z}"
+#     printf '%s\n' "export $z"
+#     printf '%s\n' "$z=$value"
+#   done
--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--


reply via email to

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