RFR: 8020779 & 8026988 : Improvements to JTReg executable location handling

Magnus Ihse Bursie magnus.ihse.bursie at oracle.com
Thu Nov 7 10:09:01 UTC 2013

On 2013-11-06 21:40, Mike Duigou wrote:
> Hello all;
> With JDK-8015068 only very recently pushed it's time for the next set of jtreg test/Makfile changes. These changes improve the configure script detection of jtreg and improve the handling of the specification variables in the jdk and langtools test/Makefiles. This changeset is also the first step in syncing the two test/Makefiles. More will follow which will further simplify the integration of testing into the overall build/test process.
> http://cr.openjdk.java.net/~mduigou/JDK-8020779/0/webrev/

I don't think the changes in toolchain.m4 does what you want it to do. 
The AC_ARG_WITH function is not really well designed. In particular, it 
is missing a "default" section. So if you use the functionality to 
execute code on "yes" and "no", then "no" will be the same wether or not 
you leave the option out alltogether, or try call it like 
--without-jtreg (or --with-jtreg=no, which is the same as --without).

Our typical use pattern, to get around this, is to not execute any code 
in the AC_ARG_WITH function, and instead check the $with_argname option 
afterwards. There you can separate the different use patterns:

* $with_argname=yes --> user explicitely set --with-argname (or 
* $with_argname=no --> user explicitely set --without-argname (or 
* $with_argname= (empty) --> user did not specify flag at all; do 
default action.
* $with_argname=<something else>  --> user explicitely set 
--with-argname=<something else>, most likely trying to override a path.

In this case, it will no longer be possible to explicitely disable jtreg 
with your changes. (If I read the code correctly -- I have not tried 
running it).

Also, the pair AC_MSG_CHECKING and AC_MSG_RESULT needs to be close 
together. If any output arrives inbetween them, the output will look 
garbled, like:

checking for foo... yes.
checking for jtreg... Rewriting path for JT_HOME to /localhome/jthome
checking for bar... no.

I tend to use the pair just consecutively after I actually found out 
what I was looking for, to avoid this. Then it's really just useful for 
the log output, not to show progress. If the test I'm about to make 
might take a non-significant amount of time, I might start by a 
AC_MSG_NOTICE([Trying to locate package foo]) or similar.

Also, if the search failed, and a AC_MSG_CHECKING had been printed, an 
AC_MSG_RESULT([no]) should be printed before AC_MSG_ERROR.


More information about the core-libs-dev mailing list