On 2013-08-08, at 9:13, Chris Hegarty <chris.hega...@oracle.com> wrote:
> On 08/08/2013 05:01 PM, Jonathan Gibbons wrote:
>> On 08/08/2013 12:00 AM, Mike Duigou wrote:
>>> On Aug 7 2013, at 20:47 , Jonathan Gibbons wrote:
>>>
>>>> On 08/07/2013 07:33 PM, Stuart Marks wrote:
>>>>> On 8/7/13 6:44 PM, Jonathan Gibbons wrote:
>>>>>> On 08/07/2013 06:22 PM, Alan Bateman wrote:
>>>>>>> It's good to see this logic going away. Also defaulting the output
>>>>>>> directory
>>>>>>> to TEST_ROOT (= pwd) is an improvement.
>>>>>> Aaargh. If I read those words correctly, it's a horrible idea to
>>>>>> set the
>>>>>> output dir to TEST_ROOT -- because on reruns jtreg will have to
>>>>>> scan the output
>>>>>> files looking for new tests!
>>>>> I liked the old behavior of the output dir being over in the build
>>>>> area. Not only does it avoid the problem that Jon mentions, but
>>>>> also, the build area is in the repo's .hgignore file. Thus all the
>>>>> generated files will be ignored by hg. If the generated files were
>>>>> to go under TEST_ROOT, it will cause "hg status" to run slowly and
>>>>> to produce voluminous output.
>>>>>
>>>>> s'marks
>>>> ^^ What he said. And the paranoid man's "make clean" of "rm -rf
>>>> build" works really well. :-)
>>>>
>>>> Writing any files into a SCM-controlled directory is a bad idea.
>>> I don't disagree but don't have any other better location to use for
>>> the default other than perhaps ../../build itself (not a config
>>> directory).
>>>
>>> The problem is that, currently, the jdk/test/Makefile can't correctly
>>> locate the build/fancy-configuration-name/testoutput directory. The
>>> logic that is in test/Makefile doesn't match the convention used by
>>> the new build infrastructure and I was unwilling to attempt to update
>>> it. To match the behaviour of the root repo makefiles it would be
>>> better to import logic from those makefiles. So far this change has
>>> been beyond the scope of my changes (though it is on my future list).
>>> Both JPRT and the root repo makefiles pass in ALT_OUTPUTDIR to
>>> test/Makefile to save the output somewhere other than into the CWD.
>>> Only running the test/Makefile directly will be impacted. I vacillated
>>> on whether to go ahead with this change but after a report that macosx
>>> output was being sent to the wrong location I opted to just scrap
>>> rather than fix.
>>>
>>> Poking whoever needs to get poked to fix JDK-8016212 would help.
>>> Having this mechanism would allow test/Makefile to access the same
>>> logic as the root repos use for determining the location of the build
>>> directory including support for CONF.
>>>
>>> Mike
>>
>>
>> I am less concerned about the cases where test/Makefile and jtreg are
>> invoked by higher level scripts, since they can override the relevant
>> settings (eg ALT_OUTPUTDIR). That leaves the case where test/Makefile
>> is being invoked directly. For my part, when working in any repo, my
>> convention is to *always* have the current directory be the root
>> directory of the repo, and to stash extra files in subdirs of the top
>> repo. You can easily enough invoke test/Makefile with "make -C test"
>> and possibly have logic to look for ../build. Also for my part, I
>> mostly ignore the fancy-config-name subdirectory -- if I'm running tests
>> locally on my laptop, I always store results in build/jtreg/{work,report}.
>
> Sounds ok to me, or just leave it where it was. I'd prefer to get the changes
> in that removes the logic to process the ProblemList, than get side tracked
> by the location
As nice as it would be to eliminate the (brokenish) platform goop I am willing
to leave it in for now. I will still try to eventually remove it and am willing
to fix reported detection mistakes (macosx amd64 is known problem)
> So we need a b07 of jtreg before we can proceed with this?
>
Yes. Since changing exclude processing doesn't block anything I am content to
hold off until jtreg 4.1_b07 is promoted for some other reason. There is a
churn cost for upgrading devs and infrastructure and this issue is not worth
that cost by itself.
Mike
> -Chris.
>
>>
>> -- Jon
>>
>>
