From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 924 invoked by alias); 25 Jul 2004 00:03:44 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 898 invoked from network); 25 Jul 2004 00:03:43 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sourceware.org with SMTP; 25 Jul 2004 00:03:43 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1BoWUR-0003uE-00 for gdb@sources.redhat.com; Sat, 24 Jul 2004 20:03:43 -0400 Received: by berman.michael-chastain.com (Postfix, from userid 502) id F322F4B104; Sat, 24 Jul 2004 20:03:44 -0400 (EDT) To: gdb@sources.redhat.com Subject: [proposal/testsuite] require build == host Message-Id: <20040725000344.F322F4B104@berman.michael-chastain.com> Date: Sun, 25 Jul 2004 01:18:00 -0000 From: mec.gnu@mindspring.com (Michael Chastain) X-SW-Source: 2004-07/txt/msg00307.txt.bz2 I'm working on a test script for the 'edit' command. In order to test the 'edit' command, the test script has to manage files on the host machine (where gdb is running), not the build machine (where dejagnu is running). A recapitulation: build runs dejagnu and the *.exp scripts host runs gcc, as, ld, and gdb target runs the test program such as "callfuncs" or "structs2" I started looking at how other gdb test scripts work in a configuration where build and host are different machines, and, well, they don't. There are about a dozen scripts that compile test files with header files, and except for list.exp, none of them download their *.h files to the host machine. gcore.exp manipulates files that gdb creates on the host machine. It needs to "remote upload" the files that gdb creates back to the build machine, but it doesn't. And so on. Of course the test suite supports a target machine which is separate from the build/host machine. That is not at issue. I don't think anyone actually uses a configuration with separate build and host. So I propose this patch to document that the gdb test suite requires that build and host be the same machine. I'll give this proposal a week for discussion. I'm hoping that the discussion goes "you're right, build-cross-host is silly and unnecessary, just drop it already", but someone may have a good reason for wanting it. Testing: I built gdbint.texinfo with makeinfo 4.7 to check the syntax. But that's not really important yet. This is about the proposal, not about the specific patch. Comments? Michael C 2004-07-24 Michael Chastain * gdbint.texinfo (Testsuite): Document that build and host must be the same machine. Index: gdbint.texinfo =================================================================== RCS file: /cvs/src/src/gdb/doc/gdbint.texinfo,v retrieving revision 1.214 diff -c -3 -p -r1.214 gdbint.texinfo *** gdbint.texinfo 1 Jul 2004 20:25:54 -0000 1.214 --- gdbint.texinfo 25 Jul 2004 00:01:08 -0000 *************** difficult to test, such as code that han *** 6315,6320 **** --- 6315,6325 ---- in particular versions of compilers, and it's OK not to try to write tests for all of those. + DejaGNU supports separate build, host, and target machines. However, + the @value{GDBN} testsuite requires that the host machine be the + same as the build machine. This requirement simplifies the writing + of test files. + @section Testsuite Organization @cindex test suite organization