On 29.11.2021 14:38, Rick McGuire wrote:
> rexx -v already includes the information "Internal Test Version" for debug
> builds. Including it
> there would be much preferred over exposing it as a language feature. We
> don't do undocument
> language features.
Double checked a Linux debug build (recreated it to make sure I was building a
debug version by
removing CMakeCache.txt and running cmake again). It would not display that
string with "rexx -v".
Also "rexx -v" does not help in situations where ooRexx is not used from the
commandline but via its
libraries at runtime. For that situation it is at least as important for
debugging/testing to learn
about a release or debug version at runtime in order to become able to log that
information.
Maybe a solution would be to have something like a RexxInfo method named
"release" which returns
.true if it is a release version and .false else?
---rony
P.S.: Here an example output using .RexxInfo to log the information about the
Rexx interpreter in
use (using a Rexx routine that formats endofline as hex string and formats
large numbers for better
legibility):
.RexxInfo:
1: ARCHITECTURE .....: 32
2: CASESENSITIVEFILES: 0
3: DATE .............: 22 Nov 2021
4: DIGITS ...........: 9
5: DIRECTORYSEPARATOR: \
6: ENDOFLINE ........: "0D0A"x
7: EXECUTABLE .......: C:\Program Files (x86)\ooRexx\rexx.exe
8: FORM .............: SCIENTIFIC
9: FUZZ .............: 0
10: INTERNALDIGITS ...: 9
11: INTERNALMAXNUMBER : 999,999,999
12: INTERNALMINNUMBER : -999,999,999
13: LANGUAGELEVEL ....: 6.05
14: LIBRARYPATH ......: C:\Program Files (x86)\ooRexx
15: MAJORVERSION .....: 5
16: MAXARRAYSIZE .....: 100,000,000
17: MAXEXPONENT ......: 999,999,999
18: MAXPATHLENGTH ....: 259
19: MINEXPONENT ......: -999,999,999
20: MODIFICATION .....: 0
21: NAME .............: REXX-ooRexx_5.0.0(MT)_32-bit 6.05 22 Nov 2021
22: PACKAGE ..........: The REXX Package
23: PATHSEPARATOR ....: ;
24: PLATFORM .........: WindowsNT
25: RELEASE ..........: 0
26: REVISION .........: 12313
27: VERSION ..........: 5.0.0
>
> On Mon, Nov 29, 2021 at 8:19 AM Rony G. Flatscher <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 29.11.2021 13:59, Rick McGuire wrote:
>> I don't think it's a good idea to have a language feature that is so
>> tightly coupled to the
>> tool used to build the interpreter. Tools change, but language features
>> are forever. Also,
>> using the CMAKE_BUILD_TYPE for the value makes it almost impossible to
>> document the return
>> values, since with CMAKE, many different build types are possible.
>
> Hmm, I see your point.
>
> How about making it an undocumented feature that is only available when
> the build type/config
> is not "release" (rather a developer's build). And instead of naming it
> "config", naming the
> method CMAKE_BUILD_TYPE to make it unmistakeingly clear that this is
> development tool (CMake)
> specific.
>
> ---rony
>
>
>>
>> On Mon, Nov 29, 2021 at 7:44 AM Rony G. Flatscher
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> In the past days I have been creating and testing various versions
>> of ooRexx on various
>> systems and
>> have been using .RexxInfo to check about revisions and bitnesses.
>>
>> Unfortunately, .RexxInfo does not have a method "config" that would
>> return "release",
>> "debug" or
>> "relwithdebinfo", depending on how ooRexx was configured at
>> compilation time which
>> sometimes is
>> important to know when debugging and analyzing the behaviour and/or
>> results.
>>
>> Looking at the RexxInfo code it should be possible to have that
>> information made available.
>>
>> If you think this might be a good idea I would volunteer to
>> implement it, using
>> CMAKE_BUILD_TYPE in
>> lowercase.
>>
>> What do you think?
>>
>> ---rony
>>
_______________________________________________
Oorexx-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
