aboutsummaryrefslogtreecommitdiffstats
path: root/find_java
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Add targetPlatform for executable binaries"Xavier Ducrohet2015-02-121-13/+14
| | | | This reverts commit 7f3cb91779907c12d02e8e5c5f4a6a7c510d210e.
* Add targetPlatform for executable binariesRaymond Chiu2015-02-101-14/+13
| | | | | | Make dsl changes due to gradle update. Change-Id: I65729783f5c8f985ed31a231e7dd9a0b9e50f7b3
* find_java.bat now uses env var instead of findDavid Herman2014-12-151-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | The officially recommended way to query an OS for its 32-bit/64-bit architecture can be found in this KB article: http://support.microsoft.com/kb/556009 Unfortunately, this fails for some subset of users for at least two reasons: 1) Many users install Unix tools on their Windows box, overwriting "find" with the Unix variant that doesn't support the \i parameter 2) Some machines are simply missing reg.exe. I've seen one claim in the wild that this was due to an agressive anti-virus scanner removing malware from their machine. Therefore, we now use absolute paths to the utilities we want to target. Additionally, we now have fallback handling if reg.exe is missing, where we, instead, rely on the %PROCESSOR_ARCHITECTURE% environment variable. Related issues: https://code.google.com/p/android/issues/detail?id=82099 https://code.google.com/p/android/issues/detail?id=82388 Change-Id: Icee0882fa6e1f5359c086498eb2679197cdf6f8e
* Fixed find_java syntax error on 32-bit machinesDavid Herman2014-12-091-1/+1
| | | | | | | Related issue: https://code.google.com/p/android/issues/detail?id=82099 Change-Id: I8241eb58d45ceca4b5ada4f5550f79376c716ed6
* find_java now locates openjdk as wellDavid Herman2014-11-241-1/+4
| | | | | | | Related issue: https://code.google.com/p/android/issues/detail?id=77218 Change-Id: I08523830c813d9cdcd303780f15f49bd5edc5ac3
* Fixed find_java JAVA_HOME minimum version bugDavid Herman2014-11-241-8/+5
| | | | | | | | | | | | If a minimum version is specified, Find Java should reject any java whose version is not at least that high. However, faulty logic ignored this contract when reading an old Java path out of the JAVA_HOME environment variable. Related to issue: https://code.google.com/p/android/issues/detail?id=80419 Change-Id: Iad935694e5b143f53074d28b8c8d7f087f9690e4
* Merge "Build and package 32/64bit find_java." into studio-1.0-devXavier Ducrohet2014-11-141-5/+11
|\
| * Build and package 32/64bit find_java.Xavier Ducrohet2014-11-071-5/+11
| | | | | | | | Change-Id: I93a2e42fb0a81d1495bb12b657b6bd6a597a128e
* | Modifed find_java.bat and build settingsDavid Herman2014-11-142-8/+23
| | | | | | | | | | | | | | | | | | Find Java now statically links in all MFC / Windows dependencies, as well as it builds to find_java32.exe and find_java64.exe. find_java.bat has been updated to take advantage of these new names. Change-Id: Iaa50d461074235dd9db750201d6e033058a2e695
* | New -path arg for find_javaDavid Herman2014-10-233-16/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the only way to specify a custom java.exe location for find_java was through JAVA_HOME, but now we have one more hook. If you pass in a custom path, and it is found, the rest of find_java will be skipped, and that path will be used. This has a few advantages: 1) Passing in an explicit custom path is really intuitive. 2) JAVA_HOME may be used by other applications, and asking users to override it for us could cause compatibility issues. 3) This makes life much easier for our installer, which does not want to blindly overwrite the user's JAVA_HOME environment variable. 4) If we ever change where we store a java path (new registry, in a file somewhere), we don't have to recompile find_java.exe to account for it. All we have to do is update find_java.bat. 5) This gives us a really easy way to tell users who run into find_java bugs a way to fix them. Change-Id: I1d7bd95c9225f34c22d987005f32af256f81d908
* | New -error arg for find_javaDavid Herman2014-10-231-6/+32
| | | | | | | | | | | | | | | | | | | | | | | | We want our installer to show a (potentially) helpful error message when find_java can't, well, find java. (Before, find_java would print nothing). After this CL is in, then if you pass -e(rror) in as an argument, find_java will either print the found java.exe path and return 0, or it will print an error message and return 1. Change-Id: I5c411ea75a8eecdb0c60aa84350a2a762a30c6d1
* | Added new -minv (version) option to find_javaDavid Herman2014-10-233-47/+85
| | | | | | | | | | | | | | | | | | find_java historically checks for v1.6, which is defined by a constant in find_java.h, and simply bumping the value up may cause problems with existing tools. Therefore, I've added an argument that takes an input minimum version to look for. Change-Id: I901dbf3621a262b3e8ee5a42ce9e46ce49126363
* | New -jdk option for find_javaDavid Herman2014-10-233-42/+84
| | | | | | | | | | | | | | | | | | find_java traditionally searched for any java.exe it could find, but recent requirements ask us to find versions of java.exe that are bundled in a JDK. This can now be done using the -jdk flag. Change-Id: I3aaba9c74271f0529d7fa16ff822b999059d578c
* | find_java now supports 64-bit buildsDavid Herman2014-10-176-77/+174
|/ | | | Change-Id: I46f2462f396c7c2f40238b7da438189b9de02a15
* find_java: new method to search in a custom pathDavid Herman2014-10-102-1/+17
| | | | Change-Id: I081871bbff9c6e714eda3e47ee16e8b486e2355b
* find_java.sln (and related project files) updatedDavid Herman2014-10-108-398/+258
| | | | | | | | - Paths needed to be updated from find_java to find_java/src/source - Some projects weren't compiling and needed to include references to various .cpp files Change-Id: I495905ef37a693d25cf34410dc395c9ae074b1da
* Fix find_java.Xavier Ducrohet2014-06-181-0/+6
| | | | Change-Id: Ib2395bd47f4a751b449a618563b438e72f76633f
* Compile find_java with Gradle.Xavier Ducrohet2014-06-116-0/+35
| | | | Change-Id: I90ff236c35a857ebde82c3d63479709474aad204
* Support for installing SDK in C:\Program FilesScott Barta2013-08-151-3/+3
| | | | | | Properly handles spaces in installation pathname on Windows. Change-Id: I8bcfd18fddbe6d5ad70a8563e8696af2876c1d1b
* Merge "SDK Launcher support sdk\tools\android.bat"Raphael Moll2012-11-261-4/+6
|\
| * SDK Launcher support sdk\tools\android.batRaphael Moll2012-11-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | The SDK Launcher is the "SDK Manager.exe" redirector that is copied at the root of an installed SDK. This change the path where it looks for android.bat so that it can also work when placed at the root of an ADT bundle. SDK Bug: 39686 Change-Id: I6222e45be5a3aca62d3557e2f8763c21c07f4f5d
* | find_java.exe: SDK tools require Java 1.6Raphael Moll2012-11-192-2/+6
|/ | | | | | | | | | | | find_java.exe is used to locate the Path to the JVM on Windows and it checks the Java version. SDK tools require Java 1.6 now. Also update the find_java error message to mention the JAVA_HOME environment variable. SDK Bug: 39876 Change-Id: I355998b10014471ccbe14ca9e977d07126b072c1
* find_java: wrap toShortPath in disableWow64FSRedirection.Raphael Moll2012-08-171-0/+3
| | | | Change-Id: I4e3135927616eb6ad3e0da46496bb97b3029ccd9
* VS8 projects for find_java/find_lock (exe & dll).Raphael Moll2012-08-174-0/+431
| | | | Change-Id: I73d08808cbf0dd7032fc481aa81ad37181930d05
* Win SDK: find max version of java.exeRaphael2012-01-313-95/+242
| | | | | | | | | | | | | | | | 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: update find_java libRaphael2012-01-272-3/+8
| | | | Change-Id: I6a139630a325f3537961cc5be2726816a060bb65
* SDK: use new find_java.exe in SDK bat filesRaphael2012-01-262-0/+64
| | | | Change-Id: I9f3fc572c3af6d8457a75cebae1aa6a850511afc
* SDK find_java, fix mingw build.Raphael2012-01-261-0/+18
| | | | Change-Id: Ic2bfe71de73ee27d44b6004dd66893374e140bba
* SDK: fix makefile for find_javaRaphael2012-01-251-4/+4
| | | | Change-Id: I7a7cdd38edfd6cc0d4272faad3df4c1c34b724cd
* Windows: "find_java" exe and lib for android.batRaphael2012-01-2511-0/+1424
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
generated by cgit v1.1 at 2024-05-18 16:36:04 +0000