summaryrefslogtreecommitdiffstats
path: root/make/scripts
Commit message (Collapse)AuthorAgeFilesLines
* wip(test_case): Example of test case for issue related of ↵Mathieu Féry2023-08-041-3/+6
| | | | | | 927bbc7160a812bb29c0e7120d4a3009bfb13bbf Almost done
* GlueGen JavaCallback: 1st Working Draft: Changed 'JavaCallbackDef' config, ↵Sven Gothel2023-06-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | added code generation incl. native to Java dispatch and resource management Tested via Test4JavaCallback.java (using test2.[hc]). Please read the GlueGen_Mapping.md as well as Test4JavaCallback.java . +++ Some implementation details: JavaConfiguration maps JavaCallbackDef to JavaCallback set-function and maintains a list. JavaCallbackDef itself holds all configured details. JavaConfiguration also maps JavaCallbackInfo to JavaCallback set-function. JavaCallbackInfo itself holds all compile time information, as produced by JavaEmitter.beginFunctions(..). This extends JavaCallbackDef and avoid repetetive computation for the callback-function-type and its MethodBinding, parameter indices for the callback interface and userParam, etc. CMethodBindingEmitter: Native callback to Java dispatch - The JavaCallback setter function creates a native 'UserParam' struct instance, which holds the callback-interface-jobject, its callback-jmethodID and the userParam-jobject for invocation of the actual JavaCallback interface method. - To produce the C-Type -> JNI-Type conversion, An internal CMethodBindingEmitter instance for the native-callback function binding is created inside the CMethodBindingEmitter of the callback setter method. It is being used to map the types to JNI within the generated native callback function, passed to the actual JavaCallback method. JavaMethodBindingEmitter: Native callback to Java dispatch - The JavaCallbacl setter passes the callback-interface-object, the userParam-object and the callback-method-signature (to have the native method retrieve the jmethodID). - It receives the native pointer of the native `UserParam` struct instance, which gets mapped to the userParam-object. (*TODO: Refine ownership + release*).
* GlueGen Struct [16]: Add support for pointer-pointer and function-pointer valuesSven Gothel2023-06-231-1/+2
| | | | See documentation and unit test test2.h, Test2FuncPtr.java and Test3PtrStorage.java
* GlueGen Test: Test2 -> Test2FuncPtrSven Gothel2023-06-231-1/+1
|
* GlueGen Struct [15]: Add FunctionPointer getter and setter support w/ ↵Sven Gothel2023-06-201-1/+2
| | | | documentation
* Roll back MacOS Min Version Requirement to 10.5 from 11.0 (macosx-version-min)Sven Gothel2023-05-041-0/+13
| | | | | | | | | | | | | | | | | MacOSX compiler configuration. 2023-05-04 Actively supported architectures are 'x86_64' and 'arm64'. XCode 14.2 on a MacOS 12.6.5 x86_64 (mac-mini) machine is capable to produce fat-lipo code for MacOS >= 10.5 for 'x86_64' and 'arm64'. The MacOS SDK 11.3 has been re-added from a previous XCode installation. However, alternative source is <https://github.com/phracker/MacOSX-SDKs>. Only for using C++ and hence the C++ STL, the minimum version is 10.7 due to clang++ libc++. This is currently the case for JOAL's bundled openal-soft, as well as for JOGL's optional oculusvr-sdk (disabled).
* HowToBuild: Windows: We use MinGW64 w/ 'posix threads' instead of 'win32 ↵Sven Gothel2023-05-041-1/+1
| | | | threads', allowing C++ std::mutex etc to be used (openal-soft)
* Windows java-win64.bat launch script: Set LIB_DIR to absolute path as ↵Sven Gothel2023-01-233-7/+6
| | | | required by System.load*()
* check-java-major-version: Add proper alt versionSven Gothel2023-01-201-1/+1
|
* Update Windows build/test scripts, remove 32-bit windows scriptsSven Gothel2023-01-176-98/+4
|
* Build scripts: MacOS + Windows: Use JDK-17 to build our Java-1.8 APISven Gothel2023-01-155-7/+7
|
* Default build is JDK-17, prepare up to Java-21 (next LTS); ↵Sven Gothel2023-01-153-0/+23
| | | | | | | | PlatformPropsImpl: Remove static OSXVersion and Version* vars, add JAVA_17 and JAVA_21 flag. PlatformPropsImpl's static OSXVersion is JOGL specific and will be moved into its GLContextImpl. PlatformPropsImpl's static Version are not required and eats up memory where it can be used transitionary.
* MacOS: Add description to produce fat OpenJDK libraries for x86_64 and aarch64Sven Gothel2023-01-141-0/+17
|
* fix windows build scriptsSven Gothel2020-01-042-3/+3
|
* all build scripts: make.gluegen.all-host-macos.sh make.gluegen.all-host-linux.shSven Gothel2020-01-022-0/+16
|
* iOS scripts: Use GLUEGEN_CPPTASKS_FILE instead of -DisIOS*=trueSven Gothel2020-01-022-2/+4
|
* Bump iOS 12.2 -> 13.2Sven Gothel2020-01-022-2/+2
|
* update make-all scriptSven Gothel2020-01-011-6/+16
|
* Bug 1417 - Android: Add adb scripts to force-stop and clear all jogamp tasks ↵Sven Gothel2019-12-262-0/+28
| | | | and packages
* Bug 1417 - Android: Add ANDROID_TOOLCHAIN_SYSROOT1_INC_STL for LLVM's C++ ↵Sven Gothel2019-12-241-10/+42
| | | | | | | | | | | | | | | | | | | STL headers (default since NDK r18) Using LLVM's c++_shared as of NDK r18: https://developer.android.com/ndk/guides/cpp-support.html LLVM's c++ headers must come before other system header! Also see https://github.com/android/ndk/issues/452 and https://gitlab.kitware.com/cmake/cmake/issues/17059 Also adapt make/lib/gluegen-cpptask-android* files: - Compiler -- align for potential C++ usage, i.e.: -- don't use '-sysroot' not '-isysroot' -- IF using C++ STL, prepend ANDROID_TOOLCHAIN_SYSROOT1_INC_STL -- just add normal sysroot headers via '-isystem' - Linker -- Use ANDROID_TOOLCHAIN_SYSROOT1_LIB1 and ANDROID_TOOLCHAIN_SYSROOT1_LIB2 for '-L' search path -- where ANDROID_TOOLCHAIN_SYSROOT1_LIB2 is for 'libc++' -> 'c++_shared'
* Bug 1417 - Android: Add ANDROID_TOOLCHAIN_SYSROOT1_INC_ARCH for arch ↵Sven Gothel2019-12-241-0/+10
| | | | | | | | | specific includes like asm/types.h Also adapt make/lib/gluegen-cpptask-android* files: - Set C++ stdlib = libstdc++ - Set isysroot (same as sysroot) - Add isystem: *_SYSROOT1_INC, *_SYSROOT1_INC_ARCH and *_SYSROOT1_INC/c++/v1
* Bug 1417 - Android: Classify SYSROOTs in NDK for native libraries (link) and ↵Sven Gothel2019-12-231-25/+39
| | | | | | | | | | | | | | | | | | | headers (compile) Utilizing '-sysroot' with the linker, we require standard FS layout. '~/Android/Sdk/ndk/20.1.5948944/platforms/android-24/arch-arm64' contains the proper std FS layout for libraries under usr/lib, but lacks the header files. We call this 'ANDROID_TOOLCHAIN_SYSROOT0' and shall be used for linking. '~/Android/Sdk/ndk/20.1.5948944/toolchains/llvm/prebuilt/linux-x86_64/sysroot' native libraries are not under std FS layout, but headers are under std FS layout for compilation under usr/include. We call this 'ANDROID_TOOLCHAIN_SYSROOT1' and shall be used for compilation. Identified while working on openal-soft Android compilation, where we need to pass ANDROID_TOOLCHAIN_SYSROOT0
* Bug 1417 - Android: Complete 1st round: ↵Sven Gothel2019-12-103-46/+48
| | | | | | | | | make/lib/gluegen-cpptask-android-<abi>.xml and scripts All aligned now - gluegen-cpptasks-android-aarch64.xml - gluegen-cpptasks-android-armv6.xml (this has ld flag --no-undefined disabled, due to internal missing symbols) - gluegen-cpptasks-android-x86.xml
* Bug 1417 - Android: Support building using current SDK and NDK v20 as of ↵Sven Gothel2019-12-102-82/+313
| | | | | | | | | | | | | | | 2019-12-10 (GlueGen w/ android-aarch64 patched) Default Platform: Android 7.0 Nougat, API level 24 supports Java 1.8 Reworked gluegen/make/scripts/setenv-android-tools.sh, following canonical environment variables and sets all required variables for cross-compilation. See file's comments! ant files: - android.version -> android.api.level (default 24) - android.jar defaults to ${gluegen.root}/make/lib/android-sdk/24/android.jar (provided)
* Scripts: Macos /opt-share -> /usr/local (Catalina Read-Only)Sven Gothel2019-12-023-9/+9
|
* Windows Regression: Mingw64 8.1.0 using statical linked tool lib ↵Sven Gothel2019-08-194-15/+18
| | | | | | | | | | | | | | | | | | | Test1p1Test1p1JavaEmitter 'com.jogamp.gluegen.test.junit.generation.Test1p1JavaEmitter' exposes a regression using MingW64 8.1.0: System.loadLibrary() gives a "Can't find dependent libraries". Here, 'Bindingtest1p1' is linked against 'test1' and fails to load due to its wrong dependent library name within 'Bindingtest1p1'. MingW64 8.1.0 dropped 'libtest1.so' into 'Bindingtest1p1.dll', which is surely wrong. Even passing '-Wl,-soname=test1.dll' didn't help. Note: Such constellation would only work with adding the lib-path to PATH on Windows. Since we don't utilize the method in any of our projects, but use the dynamic library lookup method - this is not a blocker, but wasted some good time.
* Build Update: CMake 2.8.10.2 -> 3.15.2 (Windows + MacOS), Mingw64 4.8.1 -> 8.1.0Sven Gothel2019-08-184-8/+8
|
* Bug 1363: Java 11: Fix javadoc invocation, drop -source <release> for ↵Sven Gothel2019-08-181-4/+0
| | | | | | | | | | | | | | | | | compile time javac Also prepare the 'target.releaselevel' property to be set by 'RELEASE_LEVEL' environment, however - we do not use it at this point. For now, we build gluegen-rt using '-source 1.8' '-target 1.8' and the bootclasspath of openjdk8 rt.jar to ensure java8 compatibility. Alternatively one could use '--release 8' instead using the java11 distributed modules. However, I think the above method is more safe, only allowing java8 rt.jar to be used for compilation. Further, gluegen.jar is build using '-target 1.8' only, since it musty use java11 sources at least for the javadoc taglet.
* Update HowToBuild (gawk) and windows test scriptsSven Gothel2019-08-182-6/+8
|
* Bug 1363: Java 11: Mod scripts for OpenJDK11 usageSven Gothel2019-08-1629-195/+137
|
* Merge branch 'java11'Sven Gothel2019-08-161-3/+3
|\
| * Bug 1363: Java 11: Initial Host/Target Compiler Selection: Java8Sven Gothel2019-06-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current requirements are: - Java 1.8 (Level 8.0) - Android SDK API level 24 (Version 7.0 Nougat, released August 2016) Official production builds are performed w/ Java 1.8. - Java 1.8 (Level 8.0) - Android SDK API level 24 (Version 7.0 Nougat, released August 2016) Android 7 API level 24 supports Java 1.8, see https://developer.android.com/studio/write/java8-support Java 8 is chosen today, June 2019, since OpenJDK 1.8 is well supported on desktop, mobile support is given w/ OpenJDK 9 and Android also support these language features for almost 3 years. ++++ Current patch does require one to set the target.sourcelevel, target.targetlevel and target.rt.jar properties or their equivalent capital case environment variables. Only allowed value is currently 1.8.
* | iOS: Initial iOS support commit: build.xml targets, java code-path etcSven Gothel2019-06-172-0/+70
|/ | | | | | | | | | | | Current build system for JogAmp iOS Build is: - Build Machine: OSX Mojave 10.14 - Using own (still proprietary) OpenJDK 9 iOS Build - OpenJDK 1.8 (This will be replaced by OpenJDK 11 soon) - Xcode 10.2
* Bug 1190: Define TARGET_PLATFORM_SYSROOT TARGET_PLATFORM_USRROOT ↵Sven Gothel2019-04-088-14/+18
| | | | | | | | | | | | | TARGET_PLATFORM_USRLIBS for crosscompilation Android Crosscompilation Usage: - TARGET_PLATFORM_ROOT -> TARGET_PLATFORM_SYSROOT General - TARGET_PLATFORM_SYSROOT Crosscompiler and system specified 'sysroot' (as in gcc --print-sysroot) - TARGET_PLATFORM_USRROOT Additional optional user headers and libraries for target - TARGET_PLATFORM_USRLIBS Actual location of target user libraries within TARGET_PLATFORM_USRROOT - TARGET_JAVA_LIBS Actual location of the Java libraries within TARGET_PLATFORM_USRROOT
* Bug 1190: Fix arm6hf + aarch64 gcc options, adapt glibc-compat-symbols.hSven Gothel2019-04-072-72/+0
| | | | | | - arm6hf needs the fpu to be specified, we still use the lowest armv6 hard float denominator - aarch64 shall have the -march compiler argument as well - glibc-compat-symbols.h Finally drop the glibc versioning on memcpy for both
* Bug 1190: Updating crosstools and enabling aarch64 + armv6hf 'ontarget'Sven Gothel2019-04-072-3/+3
| | | | | | | Default is to crosscompile w/o testing, i.e. property 'isCrosscompilation' is set to 'true'. 'ontarget' includes testing, no crosscompilation. Updated crosstools links to new build of jogamp-scripting commit e6692024687685d3af725555d9bb5490d85ecc8d
* Bug 1369: SCC: Hide SHA Algorithm bit size in literals of SpecificationSven Gothel2019-04-031-2/+2
| | | | | Implementation currently uses 256 bit Secure Hash (SHA) algorithm, but this may change in the future. Hence only use 'SHA' in the names, not 'SHA256'.
* Bug 1367: TempJarCache: Fix Unit Test using ReflectionsSven Gothel2019-04-031-2/+2
|
* OpenJDK8 Script Usage: Linux: Favor Debian default; Windows: Use AdoptOpenJDK8Sven Gothel2019-04-037-11/+31
|
* Bug 1369: Source Certification Contract (SCC): Initial SHA256 fingerprint & ↵Sven Gothel2019-04-031-1/+1
| | | | | | | | | | | | | | | | | | | | | runtime validation This change implements a strong SHA256 signature over: 1) source tree inclusive make recipe (SHA256-Source) 2) all class files (SHA256-Classes) 3) all native libraries (SHA256-Natives) 4) the class files as deployed in the jar (SHA256-Classes-this) 5) the native libraries as deployed in the jar (SHA256-Natives-this) and drops all of these in the deployed Jar file. This allows SHA256 validation of (4) + (5) at runtime and further complete validation (1), (2) and (3) offline. Full SCC would now required (1) - (3) to be placed on a server for further validation. Optionally we may use GPG <https://gnupg.org/> or PGP to validate the build entity to implement the chain of trust <https://en.wikipedia.org/wiki/Chain_of_trust> The SHA256 runtime validation is tested via: com.jogamp.common.util.TestVersionInfo
* Bug 1316: MacOSX: Keep *.dylib (Don't move to *.jnilib)Sven Gothel2019-03-301-1/+2
| | | | | | | | Since Java8 (or even earlier), JRE on OSX uses *.dylib native library suffix instead of *.jnilib when automatically searching and loading them. This is not easily being recognized by JogAmp, since we explicitly name the native libraries with full path when testing with our TempJarCache.
* Merge branch 'master' of git://github.com/pini-gh/gluegen into pini-gh-masterSven Gothel2019-03-261-0/+24
|\
| * Support architecture ppc64le (Debian ppc64el).Gilles Filippini2015-10-281-0/+24
| |
* | Merge pull request #25 from ghost/masterSven Gothel2019-03-264-0/+71
|\ \ | | | | | | adding support for android x86 targets - revised
| * | added android x86 support.Xavier Hallade2015-02-164-0/+71
| | |
* | | Bug 1219, Bug 1231: Re-add executable test by executionSven Gothel2019-03-253-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Re-adding executable test by execution is required for 'blocker technology' like Windows's 'Software Restriction Policies (SRP)', which only gets activated by the actual execution attempt. Merely testing the file's (ACL) execution flags via NIO's isExecutable is not sufficient. Implementation first tests the file's (ACL) execution flags via NIO's isExecutable. If the NIO test was successful or not available, the actual execution test is performed. To mitigate the virus scanner's false positive, we use an executable shell script per default now, which may be overriden by the new environment 'jogamp.gluegen.UseNativeExeFile=true' Tested on GNU/Linux with one temp folder having mount options 'noexec' and on Windows using Software Restriction Policies (SRP) disallowing one temp folder. Both temp folder were first in line via environment 'java.io.tmpdir'.
* | | Bug 1219, Bug 1231: Avoid deflating test-exe on Windows using ↵Sven Gothel2019-03-241-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | java.nio.file.Files.isExecutable(Path) Attempt to resolved virus scanner false positive detection on Windows while deflating the native code test-exe file in the temporary folder. As Julien Gouesse suggested, using Java 1.7's java.nio.file.Files.isExecutable(Path) _may_ resolve the issue, this has to be thorougly tested. This patch favors the nio's isExecutable file's ACL test over the more intrusive execution itself using a simple shell script file w/ set executable flag. Mind that previous tests allowed the shell script's execution, even if the temp folder did not allow execution of native code. We have to see how our testing results will be on this attempt.
* | | Resolve v2.3.1_winexe merge conflictsjavafxSven Gothel2019-03-201-1/+3
|\ \ \
| * | | local build windows scripts: add 7zip to pathv2.3.1_winexeSven Gothel2018-12-111-1/+3
| | | |
* | | | Merge remote-tracking branch 'remotes/xranby/aarch64'Sven Gothel2017-02-222-0/+59
|\ \ \ \
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 18:15:11 +0000