RFR: 8015068 : (m) Use jtreg -exclude for problemlist.txt processing

[Mike Duigou]

On 2013-08-08, at 9:13, Chris Hegarty <chris.hegarty at 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
>> 
>>