> 6 mar 2015 kl. 20:17 skrev Dmitry Samersoff <dmitry.samers...@oracle.com>: > > Magnus, > > You can add a generic warning: > > if configure fails finding some tools and it's solaris > then > warn about /usr/ccs/bin that should be in a path > end
This is exactly what I said would be technically hard to do. Much harder than what's justified for this issue. > > I'm against of altering PATH any way (appending or prepending anything) > because it might lead to the situation where wrong tool is picked and > it's hard to debug. I think we might just be misunderstanding each other here. Configure will not (and in fact cannot) alter the user's PATH in his/her environment. We do use the PATH as one way - but not the only way - to find tools needed to be able to build. One of the design goals of the configure script is "if the tool exist on the system, we should find it". This is to minimize the amount of configuration needed by the user. If you are worried that configure should find a tool that would work, but not be the exact version that you wanted, then you will have to point it out for configure, using eg. --with-devkit, --with-bootjdk, SED=, GREP= etc. So looking in /usr/ccs/bin instead of failing, is just like the rest of the processing configure does. /Magnus > > -Dmitry > > > >> On 2015-03-06 17:50, Magnus Ihse Bursie wrote: >>> On 2015-03-04 22:03, Martin Buchholz wrote: >>> I agree that configure should not mess with user's PATH and should >>> "auto-find" programs in /usr/ccs/bin only as a last resort. >>> >>> It would be reasonable, when configure fails on Solaris, to notice >>> that the >>> user does not have /usr/ccs/bin on PATH and suggest appending. >> >> I have opened https://bugs.openjdk.java.net/browse/JDK-8074557. >> >> Adding a warning to failed configure on Solaris due to missing build >> tools that presumably resides in /usr/ccs/bin seems like quite a lot of >> work. >> >> I suggest the following: >> Instead of prepending, append /usr/ccs/bin, so any binaries in the >> user's specified PATH are picked first. This will allow a properly set >> PATH to function, but it will still provide the "best effort" approach >> of configure to look in "well-known locations" for tools. >> >> Does that seem like an acceptable solution? >> >> /Magnus > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources.
