aboutsummaryrefslogtreecommitdiffstats
path: root/find_java/find_java_lib.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Win SDK: find max version of java.exeRaphael2012-01-311-70/+209
| | | | | | | | | | | | | | | | When we find a java.exe file, run java -version and parse its version number. Only accept java 1.5 or better. There's a moderate effort to find the highest version available in each category: for starter scripts, it doesn't matter if we actually have the highest. However within a given category (env path, program files, registry), picking up the highest available make sense. In normal cases users won't have many concurrent versions. Change-Id: I4f2504642a1712b62aa303562578572066d82d3b
* SDK find_java, fix mingw build.Raphael2012-01-261-0/+18
| | | | Change-Id: Ic2bfe71de73ee27d44b6004dd66893374e140bba
* Windows: "find_java" exe and lib for android.batRaphael2012-01-251-0/+388
This adds a "find_java.exe" that will be packages in SDK/tools/lib. It will be used by android.bat and the other launchers to locate the best version of java to use for our tools (currently we have a find_java.bat that uses DOS commands to achieve something similar but more limited). In addition this creates a static "findjavalib" that is used by the NSIS installer to locate java and get its version (to complain in case we only find a Java 1.4 or lesser). The goal is for the installer to use the same logic as the tools will use to locate the java binary. Change-Id: Ic2efb388135087bab9687c3332882047fd041b1c