I have now finally installed C68 (on QPC2) and found a bug in the SBASIC (most probably also in SuperBASIC) EX command.
Directory structure:
WIN1_bin_
WIN1_bin_c68_
c68 is installed in WIN1_bin_c68, the PATH (set with PTH device) is WIN1_bin_;WIN1_bin_c68;...
ex'cc';'hello_c'
executes cpp (the preprocessor) and then it fails with "Compilation failed". Reason is:
The compiler name (c68) is the same as the subdirectory "c68" in "WIN1_bin_". As WIN1_bin_ comes before WIN1_bin_c68_ the EX command tries to execute the directory WIN1_bin_c68_ which of course must fail. If the PATH is changed to WIN1_bin_c68;WIN1_bin_ it will compile. Would be nice if this can be corrected. E.g.the EX command should check the type and if it's a directory, it should search for the name in the directory.
Bug(?) in S(uper)BASIC EX command
Bug(?) in S(uper)BASIC EX command
http://peter-sulzer.bplaced.net
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX
GERMAN! QL-Download page also available in English: GETLINE$() function, UNIX-like "ls" command, improved DIY-Toolkit function EDLINE$ - All with source. AND a good Python 3 Tutorial (German) for Win/UNIX
-
- Font of All Knowledge
- Posts: 3928
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
Re: Bug(?) in S(uper)BASIC EX command
HI Peter,
I do not think this is bug, only your system not being setup correctly, consulting the C68 manual, the C68 compiler defaults can be set with Environmental Variables.
Here is a fragment from my boot file, line numbers omitted:
Set the C68 Environmental varaibles:
Now I set the Path setting:
Now set the DATAD$ and PROGD$ to PTH1_
Compiles and links the C68 file 'hello_c' and produces an executable called 'hello_exe'
The DATAD$ and PROGD$ could be set to WIN1_ or what ever default device used, the environmental variables take care of the C68 path and defaults.
The C68 defaults can be overridden in the command line or in a make file.
I do not think this is bug, only your system not being setup correctly, consulting the C68 manual, the C68 compiler defaults can be set with Environmental Variables.
Here is a fragment from my boot file, line numbers omitted:
Set the C68 Environmental varaibles:
Code: Select all
REMark Set variables for C68
SETENV "CC_PATH=win1_c68_"
SETENV "CC_OPTS=-v -lm"
SETENV "CC_CPP=cpp"
SETENV "CC_COMP=c68"
SETENV "CC_ASM=as68"
SETENV "CC_LD=ld"
SETENV "CC_INC=win1_c68_Include_"
SETENV "CC_LIB=win1_c68_Lib_"
Code: Select all
REMark setup Path Search
PTH_ADD "win1_"
PTH_ADD "win1_turbo_"
PTH_ADD "win1_asm_"
PTH_ADD "win1_c68_"
Code: Select all
DATA_USE "PTH1_
PROG_USE "PTH1_"
Code: Select all
ex cc;'hello_c -o hello_exe'
The DATAD$ and PROGD$ could be set to WIN1_ or what ever default device used, the environmental variables take care of the C68 path and defaults.
The C68 defaults can be overridden in the command line or in a make file.
Regards,
Derek
Derek
Re: Bug(?) in S(uper)BASIC EX command
This seems to be caused by the way you set up your pth device, but is definitely not a bug in EXEC.
EXEC has no ambitions whatsoever to "repeat until an executable file is found" - If you give it a file name which is not an executable, it will just fail (which is good).
the pth device will search through all its stored directories until it finds a file with a given name - It doesn't promise that file will be of any specific type (it doesn't even know what type you want).
In your case, it finds a file with the required name, which just happens to be a directory, and hands that to EXEC - that one sees it's not an executable file and does what it is expected to: It fails. All good in my opinion.
The secret for making this work is the order of the entries in the pth device driver's search lists. While you might be tempted to order these from coarse to fine (i.e. upper-layer directories first, as you have done), you should instead do that the other way round from fine to coarse (depth-first). Simply reverse the PTH_ADD commands to have pth search the sub-directories first rather than last, and you should be fine.
EXEC has no ambitions whatsoever to "repeat until an executable file is found" - If you give it a file name which is not an executable, it will just fail (which is good).
the pth device will search through all its stored directories until it finds a file with a given name - It doesn't promise that file will be of any specific type (it doesn't even know what type you want).
In your case, it finds a file with the required name, which just happens to be a directory, and hands that to EXEC - that one sees it's not an executable file and does what it is expected to: It fails. All good in my opinion.
The secret for making this work is the order of the entries in the pth device driver's search lists. While you might be tempted to order these from coarse to fine (i.e. upper-layer directories first, as you have done), you should instead do that the other way round from fine to coarse (depth-first). Simply reverse the PTH_ADD commands to have pth search the sub-directories first rather than last, and you should be fine.
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO