Different people have different preferences, for various reasons, and I try to learn from others, specially from the people, who are smarter/more_experienced ones, so I really do NOT want to say that what I propose is necessarily even appropriate, but if I do not make the proposals or say/write, what I think, then I won't get the feedback about my stupidity, lack of knowledge, poor skills. So, with that in mind, I propose that the build "process"/script/procedure should run a quick check, whether all of the needed tools are available on the command line and if even one of them is missing, then just abort, tell the name of the missing command line tool and the reason for aborting. Some sort of a wrapper around the
which name_of_the_tool_that_is_supposed_to_be_on_the_PATH
I'm not saying that it should be Bash, which isn't even available on Windows and not even a default shell in all cases, but to illustrate the idea that might be added as part of the gprbuild:
# At the start of my Bash scripts I tend to use
S_FP_ORIG="`pwd`" # which is used at the various functions
# as show below
func_mmmv_exit_if_not_on_path_t2() { # S_COMMAND_NAME
local S_COMMAND_NAME=$1
local S_LOCAL_VARIABLE="`which $S_COMMAND_NAME 2>/dev/null`"
if [ "$S_LOCAL_VARIABLE" == "" ]; then
echo ""
echo "Command \"$S_COMMAND_NAME\" could not be found from the PATH. "
echo "The execution of this Bash script is aborted."
echo "GUID=='455b5615-c335-4ee1-9e03-e1d141816ed7'"
echo ""
cd "$S_FP_ORIG"
exit 1;
fi
} # func_mmmv_exit_if_not_on_path_t2
# I have a Ruby based command line tool for updating
# all of the GUIDs in the file that is open in Vim,
# so that error message code blocks can be copy-pasted
# without manually updating the GUIDs. That way
# it's easy to find the exact code region, where the
# GUID originated from. I started to use the GUIDs
# like that at an era, when web browsers did not have
# debuggers, so I wrote all of my JavaScript, if described in "pseudocode"
#
# function Foo(){
# try{
# the real thing
# } catch (err){
# throw(err,<custom GUID>)
# }
#
# giving me a stack trace of GUIDs at the JavaScript coonsole
# and then I created a KomodoIDE/KomodoEdit plugin (a few plugins) that read that
# stack of GUIDs in from a text file and I was able to move up and down
# at that stack by having the IDE opening the actual original source file
# form me from the location, where the GUID resided at the original source code.
# Even with modern web browser debuggers the debugger opens the JavaScript file that
# the web browser has, not the original source file, which does not have to be
# JavaScript, that got used for building the JavaScript that the web browser executes.
#
# I am NOT necessarily reccomending my tools, but that's what I use:
# https://github.com/martinvahi/mmmv_devel_tools/tree/master/src/mmmv_devel_tools/GUID_trace/src/UpGUID
# The mmmv_devel_tools is a mess in a sense that once upon a time
# it supported the latest Ruby, but at Ruby 2.4.0 they deprecated an integer
# type there (Fixnum/Bignum -> Integer) and I haven't updated all of it,
# but some parts work with newest Ruby and
# some require the old Ruby and I do not remember,
# which is which, I just have it set up at my own computer as a dirty hack.
# Obviously I need to fix it.
An example, where the the testing of the availability of different command line tools could become very useful is
#...(The rest of the console output on 64b Linux)
[Ada] psc-link_names.ads
[Ada] psc-interpreter-param_sig.ads
[Ada] psc-interpretations.adb
cd testsuite/ParaSail; ../support/clean.sh
cd testsuite/Sparkel; ../support/clean.sh
cd testsuite/Ada202x; ../support/clean.sh
cd testsuite/Parython; ../support/clean.sh
cd testsuite/Javallel; ../support/clean.sh
gprbuild -p -p -g -O0 -gnato -gnata -gnatE -P build/parasail -largs
Bind
[gprbind] parasail_main.bexch
[Ada] parasail_main.ali
Link
[link] parasail_main.adb
cd lib; ../share/tools/vi_tags/psltags aaa.psi reflection.ps? llvm_printer.ps? compiler.ps? psvm_debugging.psl parascope.ps? vn_il.ps? type_desc_llvm_utils.ps?
/bin/sh: 1: ../share/tools/vi_tags/psltags: not found
make: *** [Makefile:94: lib/tags] Error 127
warc_librarian@hoidla-01:~/tmp_/compile_test_001$ ls
ada202x_examples bin documentation javallel_examples _linux parser semantics sparkel_parser
ada202x_parser build examples javallel_parser _mac parython_examples share testsuite
aflex_ayacc design interpreter lib Makefile parython_parser sparkel_examples _win
warc_librarian@hoidla-01:~/tmp_/compile_test_001$ ./share/tools/vi_tags/psltags
-bash: ./share/tools/vi_tags/psltags: /bin/csh: bad interpreter: No such file or directory
warc_librarian@hoidla-01:~/tmp_/compile_test_001$ which csh
warc_librarian@hoidla-01:~/tmp_/compile_test_001$
which got "solved" after installing the csh like
#...(the rest of the console output)
[Ada] psc-interpreter-param_sig.ads
[Ada] psc-interpretations.adb
cd testsuite/ParaSail; ../support/clean.sh
cd testsuite/Sparkel; ../support/clean.sh
cd testsuite/Ada202x; ../support/clean.sh
cd testsuite/Parython; ../support/clean.sh
cd testsuite/Javallel; ../support/clean.sh
gprbuild -p -p -g -O0 -gnato -gnata -gnatE -P build/parasail -largs
Bind
[gprbind] parasail_main.bexch
[Ada] parasail_main.ali
Link
[link] parasail_main.adb
cd lib; ../share/tools/vi_tags/psltags aaa.psi reflection.ps? llvm_printer.ps? compiler.ps? psvm_debugging.psl parascope.ps? vn_il.ps? type_desc_llvm_utils.ps?
csh share/tools/vi_tags/do_atags.csh
ln: failed to create symbolic link '../ada2020_library/tags': No such file or directory
make: *** [Makefile:89: tags] Error 1
make: *** Deleting file 'tags'
warc_librarian@hoidla-01:~/tmp_/compile_test_001$ uname -a
Linux hoidla-01 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) x86_64 GNU/Linux
warc_librarian@hoidla-01:~/tmp_/compile_test_001$
One of the aspects of testing the availability of the console tools is that they might be required to exist conditionally and the conditions depend on the rest of the build system, build parameters. Probably the tests need to be kept in line with the actual requirements manually, which is another source of human errors. But, it does simplify the task of giving reasonable error messages. In stead of having a message, "psltags not found", there might be a more appropriate message telling: "csh not found, but it MIGHT be possible to manually install it from the operating system distribution package collection."
It's just an idea, thank You for reading my comment.