#1840: Config step to detect RTEMS
-----------------------+----------------------------------------------------
Reporter: dukeleto | Owner: jkeenan
Type: feature | Status: assigned
Priority: normal | Milestone: 2.10
Component: configure | Version: 2.10.0
Severity: medium | Keywords:
Lang: | Patch:
Platform: |
-----------------------+----------------------------------------------------
Comment(by doughera):
Replying to [comment:7 jkeenan]:
> Replying to [comment:6 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.
--
Ticket URL: <https://trac.parrot.org/parrot/ticket/1840#comment:8>
Parrot <https://trac.parrot.org/parrot/>
Parrot Development
_______________________________________________
parrot-tickets mailing list
[email protected]
http://lists.parrot.org/mailman/listinfo/parrot-tickets
