Thomas Seiler wrote:
Couldn't we split the probing into two phases ?
Let's asume for a moment that it's easy to build a miniparrot for ethier the host or the target.
The first phase would run on the host and prepare the tests and a miniparrot for the target, but not run them.
The seconde phase would run on the target and run the actual test, while populating a Configuration file.
Host Phase:
- Build host version of miniparrot
- Build target version of miniparrot (use cross compiler)
- Build all probing programms and test cases (use cross-compiler)
- Populate a sub-directory with target miniparrot and the remaining test programms
Target Phase: - Copy that directory to the target - Run the configuration phase and get the Config file
The challange would be to get the miniparrot running on the target.
All the rest should be covered by the "normal" Parrot Configuration Probing.
This is about as general as it can get, or am I missing something ?
The problem is that getting stuff on and off your target host is not always trivial. Typically, if you can do what you describe, you don't need to perform cross compilation: you can simply compile on your target (not always, sometimes you may want to build a couple different architectures at once, even if they are all unixy, or you may not have a compiler on the target (think Windows)).
It is especially not true in the embedded world. Until I have parrot IO libraries, I am not going to be getting a whole lot out of the target. You could write the results in memory and then dump it, but ... well, it seems simpler to hand supply the config information. Trying to get answers from an embedded target is tricky and sometimes even potentially dangerous.
Gregory Keeney
Thomas Seiler
