The -gnat95 Option Seems to fail

[Martin Vahi]

I downloaded theParaSail 8.4 and did

make clean

make

and got

#....(the rest of the console output)
splitting ../build/parasail_tokens.ads into:
   parasail_tokens.ads
rm -rf parasail*.ad? parasail.y parasail_lex.l
make[1]: Leaving directory '/home/ts2_andmed/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4/parser/build'
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 -gnat95 -P build/parasail -largs
Compile
   [Ada]          parasail_main.adb
gnat1: invalid switch: -gnat95

   compilation of parasail_main.adb failed

gprbuild: *** compilation phase failed
Makefile:117: recipe for target 'parasail' failed
make: *** [parasail] Error 4
ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ gnat --version
GNAT Community 2019 (20190517-83)
Copyright (C) 1996-2019, Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ gprbuild --version
GPRBUILD Community 2019 (20190517) (x86_64-pc-linux-gnu)
Copyright (C) 2004-2019, AdaCore
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ uname -a
Linux linux-f26r 4.4.126-48-default #1 SMP Sat Apr 7 05:22:50 UTC 2018 (f24992c) x86_64 x86_64 x86_64 GNU/Linux
ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ date
Mon Nov  4 19:15:10 EET 2019
ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$

Is it just me doing something wrong or is there a bug? Thank You.

[Tucker Taft]

You can just remove the switch.  It was there to be sure that the sources could be compiled by "any" Ada 95 compiler.  I am surprised it isn't recognized any more -- I'll have to find out why.  I see you are on linux using the Community edition.  Perhaps that switch has been dropped from the latest Community release.    I know going forward AdaCore was only going to be supporting Ada 2012 for Community editions, so I suppose this is part of that choice...

Thanks for the heads up.

Take care,

-Tuck

--
You received this message because you are subscribed to the Google Groups "ParaSail Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parasail-programming...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/parasail-programming-language/4c6f8c51-44e7-4451-ae1a-4e436715c1a8%40googlegroups.com.

[Martin Vahi]

I hazily remembered that the Ada95 support was supposed to be thrown out of the AdaCore GNAT Community newest versions (my vagueness comes from the fact that I really do not know/use Ada), so I tried an older version and I also tried the one that comes from the OS package collection. I did it so that I had the gprbuild on PATH from the newest AdaCore GNAT Community. I got rid of the -gnat95 complaint, but ended up stumbling on a new one:

#....(the rest of the console output)
splitting ../build/parasail_tokens.ads into:
   parasail_tokens.ads
rm -rf parasail*.ad? parasail.y parasail_lex.l
make[1]: Leaving directory '/home/ts2_andmed/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4/parser/build'
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 -gnat95 -P build/parasail -largs

No valid configuration found
Generation of configuration files failed
GNAT-TEMP-000001.TMP:1:01: "project" expected
gprbuild: processing of configuration project "/tmp/GNAT-TEMP-000001.TMP" failed

Makefile:117: recipe for target 'parasail' failed
make: *** [parasail] Error 4

ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ gprbuild --version
GPRBUILD Community 2019 (20190517) (x86_64-pc-linux-gnu)
Copyright (C) 2004-2019, AdaCore
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4$ gnat --version
GNAT Community 2018 (20180524-73)
Copyright (C) 1996-2018, Free Software Foundation, Inc.

[Tucker Taft]

This looks like an installation issue.  Try to compile a simple Ada program and see whether it works.  In any case, I have attached a replacement for the Makefile and the various .gpr files, which just removes the "-gnat95" switch.

-Tuck

--
You received this message because you are subscribed to the Google Groups "ParaSail Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parasail-programming...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/parasail-programming-language/27167756-cf02-4cd4-9251-5b11d9e0c9a4%40googlegroups.com.

[Martin Vahi]

Thank You. However, a file named compiled_main.gpr seems to be present at 2 places and they seem to differ and I suspect that You might have patched just one of them. I can make the few text edits at my copy, but You may want to update Yours.

ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4_ttrm_gnat95_mall$ diff ./testsuite/support/compiled_main.gpr ./build/compiled_main.gpr
3,4c3,5
<    for Object_Dir use "../../../build/obj";
<    for Exec_Dir use ".";
---
>    for Object_Dir use "fast_obj";
>    -- for Object_Dir use "slow_obj";
>    -- for Exec_Dir use "..";
6c7
<    for Source_Dirs use ("../../../semantics", "../../../interpreter");
---
>    for Source_Dirs use ("../semantics", "../interpreter");
12c13
<       for Default_Switches ("ada") use ("-s", "-g", "-k");
---
>       for Default_Switches ("ada") use ("-s", "-O2", "-g", "-k", "-gnatN");
16,17c17,19
<       for Default_Switches ("ada") use ("-gnatE", "-fstack-check",
<         "-g", "-gnata", "-gnat95");
---
>       for Default_Switches ("ada") use
>            ("-gnatE", "-fstack-check",
>             "-O2", "-g", "-gnat95", "-gnatU", "-gnatN");
21c23
<       for Default_Switches ("ada") use ("-g");
---
>       for Default_Switches ("ada") use ("-O2", "-g", "-L/usr/lib", "-L.", "-ltermcap");
ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4_ttrm_gnat95_mall$ diff ./build/compiled_main.gpr ./2019_11_04_patchwork/compiled_main.gpr
19c19
<             "-O2", "-g", "-gnat95", "-gnatU", "-gnatN");
---
>             "-O2", "-g", "-gnatU", "-gnatN"); -- "-gnat95" no longer supported
ts2@linux-f26r:~/m_local/bin_p/ParaSail/v2019_11_04_v_8_4/parasail_release_8_4_ttrm_gnat95_mall$

[Martin Vahi]

I suspect that may be there should be 2 testing modes, one, where the -gnat95 is present and another one, where it is absent. May be there are also other compiler parameters that differ between compilers or compiler versions. I do not know. It's just a random thought.

[Tucker Taft]

Thanks for pointing this out.  Not wise to have the same filename appear in two different places!  The testsuite scripts may need a bit of cleanup...

Take care,

-Tuck

--
You received this message because you are subscribed to the Google Groups "ParaSail Programming Language" group.
To unsubscribe from this group and stop receiving emails from it, send an email to parasail-programming...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/parasail-programming-language/1020f662-7c22-4c9b-9da5-50d075c16f09%40googlegroups.com.

[Martin Vahi]

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.


[Tucker Taft]

Thanks for the suggestions.  You are right that there is a big presumption that /bin/csh exists.   At a minimum we should indicate that in the release notes.  If it doesn't exist, not clear what could be done other than grind to a halt, or rewrite all the scripts in bash or equivalent. ;-)

I also just fixed the problem you bumped into later with ada2020_library not existing.  If you (or others ;-) re-download the 8.4 release then the problems you identified should be resolved (except this most recent one about the undocumented dependence on /bin/csh).

Take care,

-Tuck

On Tue, Nov 5, 2019 at 9:30 AM Martin Vahi <sininet...@gmail.com> wrote:

...

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