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
>> 
>> 

Reply via email to