This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: QMTest and the G++ testsuite




--On Monday, May 20, 2002 01:49:06 PM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On May 20, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
>
>> At present, you can specify an "interpreter" which is supposed to have
>> the property that:
>
>>   interpreter program arg1 arg2 ...
>
>> Now, there is the question of writing the interpreters for various
>> setups; you need the logic to zap the code to the target board, run it,
>> extract the output, zap it back.
>
> How about running the *build* on a separate machine?

There's no major conceptual problem here; just a matter of
plugging in the right bits.  (QMTest is quite modular; it's easy to plug
new stuff like this in.)  In fact, all the places where the framework
runs the compiler are in a single function; all we need to do is add
the right gunk in there to invoke whatever magic needs to be invoked.

I'll promise that QMTest's architecture is capable of all this
cross-compilation magic.  We just need to do the work to slot in the
right pieces.

The important question is whether we think it's worth doing.

And to do that, I think we can stick to the native toolchains for the
time being; your goal should be to answer the question

  If Mark is right, and this will work in cross environments, would I
  want to have it?  Or would I rather stick with DejaGNU?

I think it's more efficient to work this way than to implement every
imaginable cross-compilation contingency before making the evaluation.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]