Config step to detect RTEMS

[dukeleto]

We need a config step that checks for rtems and sets the parrot_config key of 'rtems' to true or false, depending on whether the symbol is defined.

[dukeleto]

We probably want to actually store the string 'rtemsx.x' where x.x is the version of RTEMS in whichever config key stores the name of the operating system.

[jkeenan]

Adding link for reference to  rtems.com.

BTW, their web site has a great discussion of their use of  Coverage Analysis in testing.

kid51

[doughera]

> Comment(by dukeleto):
> 
>  We probably want to actually store the string 'rtemsx.x' where x.x is the
>  version of RTEMS in whichever config key stores the name of the operating
>  system.

"osname" is currently set by config/auto/arch.pm, based on perl5's 
$Config{archname}, which, in turn, is based on the output of `uname -a`, 
along with a lot of other heuristics accumulated over the years. 
Presumably, there is some existing file one could test for or existing 
command one could run to determine if this is RTEMS or not.

Parrot doesn't generally use perl5's Config{osvers}, though parrotbug uses 
it in bug reports.  Oddly, init/hints/freebsd.pm recomputes $osversion, 
but never uses it.  I think it would make sense to add an "osvers" key to 
the existing "cpuarch" and "osname" keys in the config/auto/arch.pm step.

--
    Andy Dougherty		doughera@lafayette.edu

[jkeenan]

Replying to dukeleto:

We need a config step that checks for rtems and sets the parrot_config key of 'rtems' to true or false, depending on whether the symbol is defined.

dukeleto:

Please do a checkout of the gcc_defines branch from Subversion and configure on the machine where you have RTEMS. Then call grep -i gccdefines__rtems__ lib/Parrot/Config/Generated.pm config_lib.pir. Then tell me if you can take it from there.

(Don't merge. There are other issues I'll deal with.)

Thank you very much.

kid51

[doughera]

Replying to jkeenan:

Please do a checkout of the gcc_defines branch from Subversion and configure on the machine where you have RTEMS. Then call grep -i gccdefines__rtems__ lib/Parrot/Config/Generated.pm config_lib.pir. Then tell me if you can take it from there.

I'm unsure if this will be useful. For comparison, perl 5's Configure also attempts to figure out the symbols #defined for the the current C preprocessor. It's over 200 lines of shell code, running from line 21,467 to 21,687 in Configure. The output is stored in $Config{cppsymbols}. As far as I know, the output is no longer ever used.

Within C code, if you want to check #ifdef __rtems__, you simply do so. You don't need any Configure probe. Outside of C code, I agree you need to run some kind of probe, but this looks overly complicated to me. As I have mentioned previously in this ticket, I think the osname probe is the more natural place to do this.

[jkeenan]

Replying to doughera:

Outside of C code, I agree you need to run some kind of probe .... [T]he osname probe is the more natural place to do this.

Andy,

Thanks for taking another look at this.

Here I'm bumping up against the limits of my understanding of the problem we're trying to address in this ticket. Are we:

* checking to see whether the OS on which we are trying to configure and build Parrot is RTEMS? If so, then I would ask dukeleto: What do you get on your RTEMS box for osname in lib/Parrot/Config/Generated.pm.

or:

* checking to determine whether the box on which we are working (and which is presumably capable of compiling Parrot) is capable of (cross-)compiling RTEMS?

kid51

[doughera]

Replying to jkeenan:

Replying to doughera:

Here I'm bumping up against the limits of my understanding of the problem we're trying to address in this ticket. Are we: * checking to see whether the OS on which we are trying to configure and build Parrot is RTEMS? or: * checking to determine whether the box on which we are working (and which is presumably capable of compiling Parrot) is capable of (cross-)compiling RTEMS?

I think it's more the latter. Parrot's configure system doesn't include separate concepts of "host" and "target" systems, so something is going to have to force it somewhere. Somehow, in the command-line invocation of Configure.pl, the user must indicate that cross-compiling is desired.

There are many ways one might imagine that working, and, hence, many different ways one might imagine the relevant Configure steps working. Hence confusion results.

I think that dukeleto might have the following scenario in mind:

If the user wishes to cross-compile for RTEMS, then he or she specifies the cross-compiler for the -cc= (and -ld=, -link=, etc.) command-line options to Configure.pl. Then, in auto:cpuarch, Configure.pl could build the following simple program

#include <stdlib.h>
int main(int argc, char **argv)
{
#ifdef __rtems__
    exit EXIT_SUCCESS;
#else
    exit EXIT_FAILURE;
#endif
}

compile it with the supplied compiler, run it, and check the return status. I don't know RTEMS at all, so I don't know how one actually runs such a cross-compiled command. For some cross-compilation set-ups, actually running the command is difficult (it requires transferring the compiled program to another device.) In such cases, it might be better to try just compiling something like this instead:

#include <stdlib.h>
int main(int argc, char **argv)
{
#ifdef __rtems__
    exit EXIT_SUCCESS;
#else
    error_undefined_variable;
#endif
}

If this compiles at all, then we are on rtems. This would solve the immediate problem, but I suspect it will be insufficient to solve the whole cross-compiling program. Other parts of the build system will also likely need to become cross-compiling aware.

Ideally, it would be nice to determine that osname=rtems (and hence that we are cross-compiling) much earlier in the process (before init::hints) so that one could write and use a config/init/hints/rtems.pm hint file, instead of sprinkling if($PConfig{$rtems}) statements throughout all the other config files. If Configure.pl allowed the user to specify arbitrary config keys from the command line, one might imagine accomplishing this by writing something like

Configure.pl --with-osname=rtems

but Configure.pl does not currently allow that. Alternatively, the autoconf cross-compilation command-line syntax might offer a good model for what users would actually like to do, but extending Configure.pl in that direction is a different job for a different ticket.

I hope this helps a little.

[dukeleto]

The code snippets above are exactly what is needed by the C probe. Cross-compiling concerns will be taken care of in other tickets.

I agree with Andy that we will need a config/init/hints/rtems.pm in the future.

[jkeenan]

Replying to doughera:

> 
> I think it would make sense to add an "osvers" key to 
> the existing "cpuarch" and "osname" keys in the 
> config/auto/arch.pm step.
> 

I've created TT #1841 to discuss this issue by itself.

kid51

[jkeenan]

Try svn up again after r49770.

[jkeenan]

Replying to jkeenan:

dukeleto:

Since there is nothing more I can do about this issue right now, I am going to reassign this ticket to you. You can take it up whenever you get back to hacking on RTEMS.

Thanks.

kid51