This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [gofrontend-dev] [PATCH 4/4] Gccgo port to s390[x] -- part II
- From: Ian Taylor <iant at golang dot org>
- To: Dominik Vogt <vogt at linux dot vnet dot ibm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, "gofrontend-dev at googlegroups dot com" <gofrontend-dev at googlegroups dot com>, Ian Taylor <iant at golang dot org>
- Date: Thu, 6 Nov 2014 09:06:18 -0800
- Subject: Re: [gofrontend-dev] [PATCH 4/4] Gccgo port to s390[x] -- part II
- Authentication-results: sourceware.org; auth=none
- References: <20141104121552 dot GE19710 at linux dot vnet dot ibm dot com> <CAOyqgcWjR5rbomTYsyJxQaJKVti_QKHZ5k0oeaH3-t3bz7Sr4A at mail dot gmail dot com> <20141105100511 dot GB3520 at linux dot vnet dot ibm dot com> <20141106120425 dot GA19995 at linux dot vnet dot ibm dot com>
On Thu, Nov 6, 2014 at 4:04 AM, Dominik Vogt <vogt@linux.vnet.ibm.com> wrote:
> On Tue, Nov 04, 2014 at 08:16:51PM -0800, Ian Taylor wrote:
>> The way to do it is not by
>> copying the test. If the test needs to be customized, add additional
>> files that use // +build lines to pick which files is built. Move
>> them into a directory, like method4.go or other tests that use
>> "rundir".
>
> Currently go-test.exp does not look at the "build" lines of the
> files in subdirectories. Before I add that to the gcc testsuite
> start adding that, is it certain that the golang testsuite will be
> able to understand that and compile only the requested files?
Hmmm, that is a good point. The testsuite doesn't use the go command
to build the files in subdirectories, so it won't honor the +build
lines. I didn't think of that. Sorry for pointing you in the wrong
direction.
I'd still like to avoid the rampant duplication if possible. One
approach would be to put most of the test in something like
nilptr_tests.go marked with "// skip". Then we can have top-level
nilptrXX.go tests with +build lines that use "// run nilptr_tests.go".
(By the way, it's not "golang;" it's "Go." Please try to avoid the
term "golang." Thanks.)
Ian