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=yes)
* $with_argname=no --> user explicitely set --without-argname (or
--with-argname=no)
* $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
yes.
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.
/Magnus
