linux/meta-java.git/recipes-core/cacao, branch morty

java-bootstrapping: Do not rely on hardcoded paths

2016-04-29T10:17:07+00:00

Various paths to files are hardcoded in either helper scripts or the resulting binaries (like path to Java class libraries). While this works well when using the files on the build machine, things start breaking down when the sstate gets shared between multiple workers in CI, as the paths between workers can differ. Instead of using these hardcoded paths, form the paths at runtime and pass them as parameters when required. Signed-off-by: Erkka Kääriä Signed-off-by: Maxin B. John

cacao: remove invalid configure options

2016-01-29T09:37:51+00:00

These configure options are invalid: --with-classpath-libdir --with-classpath-classes --with-classpath-includedir They had been replaced by: --with-java-runtime-library-libdir --with-java-runtime-library-classes --with-jni_h and --with-jni_md_h Remove them to avoid QA Issue: WARNING: QA Issue: cacao-native: configure was passed unrecognised options: --with-classpath-libdir --with-classpath-includedir --with-classpath-classes [unknown-configure-option] Signed-off-by: Jackie Huang Signed-off-by: Maxin B. John

openjdk-8-native: fix improper do_install and PROVIDES

2016-01-04T11:21:06+00:00

We had: virtual/jar-native provided by fastjar-native virtual/java-native provided by cacao-native and jamvm-native virtual/javac-native provided by ecj-bootstrap-native Then openjdk-8-native added and also provides: virtual/java-native and virtual/javac-native (it also installs ${STAGING_BINDIR_NATIVE}/jar but doesn't add virtual/jar-native in the PROVIDES) which introduces circular dependencies, java-bootstrap-components.bbclass is to avoid the circular dependencies but it's not a correct way since it make two conflicted packages build into the same sysroot: DEPENDS_prepend_class-native = " ecj-bootstrap-native " DEPENDS_prepend_class-target = " virtual/javac-native " virtual/javac-native is provided by openjdk-8-native, and it assumed that ecj-bootstrap-native, fastjar-native and cacao-native/jamvm-native are always built before openjdk-8-native, then in the do_install of penjdk-8-native, it removes them from staging dirs first, then install (create symlinks for) these files in staging dirs directly, which results with empty sstate and builds from sstate cache or builds not in this assumption will fail. The fixes here includes: - Revert "meta-java: rely on well known bootstrap-path" in previous commit to remove the improper java-bootstrap-components.bbclass - Do not let openjdk-8-native provides jar, java and javac, just like what we do in icedtea7-native, which can provides but not to avoid circular dependencies and conflicts. - make cacao-native back to provide virtual/java-native, and ecj-bootstrap-native back to provide virtual/javac-native - Add back provider settings in README. - Remove the update-alternatives in openjdk-8-native, it doesn't work for native package. Signed-off-by: Jackie Huang

Revert "meta-java: rely on well known bootstrap-path"

2016-01-04T11:21:06+00:00

This reverts commit 04d5d0bf414c05ca59618d77f17ff9898aa1c566. Detail reason is in the following commit. Signed-off-by: Jackie Huang

cacao: fix the depends for target package

2015-12-17T12:39:21+00:00

The target package also depends on classpath, zlib, etc, which is incorrect overrode, use _append for the class-target instead. Signed-off-by: Jackie Huang Signed-off-by: Otavio Salvador

openjdk-8: add recipes for openjdk-8 and openjre-8

2015-12-08T15:43:40+00:00

This adds openjdk-8 for native and target builds and allows a stripped openjre-8 being built as well instead of trying to cherry-pick jre components from jdk-image. The recipes allow building openjdk-8 with or without: * x11 * cups * alsa/pulseaudio and let packager enable unlimited-crypto, if desired. To support certificate based java libraries, cacerts is created based on ca-certificates from OE-core. Since there can be only one PROVIDES for virtual/java-native and virtual/javac-native, move the provides to openjdk-8-native (I think everyone agrees it's a better choice than ecj-bootstrap-native). Plus: Applying a fix from openjdk-9 repository which fixes build issues using gcc5 Signed-off-by: Jens Rehsack Signed-off-by: Maxin B. John

meta-java: rely on well known bootstrap-path

2015-12-08T15:43:35+00:00

Instead of potential circular depending virtual/javac-native (even this recipe provides such a useable java-native), rely on well known path via cacao-native to build up to icedtea7-native in reliable manner. virtual/javac-native should be used by parts not belonging to the bootstrap phase. Signed-off-by: Jens Rehsack Signed-off-by: Maxin B. John

cacao: fix configure error

2015-11-03T10:24:34+00:00

This patch fixes the nowadays occuring configure error: rm: cannot remove 'src/mm/boehm-gc/ltmain.sh': No such file or directory Signed-off-by: Jens Rehsack Signed-off-by: Maxin B. John

Avoid parse time errors due to dependency on x11, for distros without x11

2015-10-29T11:02:28+00:00

BitBake raises some errors when processing recipes that depend on x11 for distros that don't have x11 in DISTRO_FEATURES. To work around that issue, REQUIRED_DISTRO_FEATURES = "x11" (from distro_features_check.bbclass) has been set for the following recipes: * cacao (_class-target) * classpath (_class-target) * jamvm (_class-target) * openjdk-7-release That makes BitBake skip those recipes during the cache generation (they'd still be parsed, but ignored). This patch improves the idea from Mario Domenech Goulart Signed-off-by: Jens Rehsack Acked-by: Richard Leitner Signed-off-by: Otavio Salvador

cacao-initial-native: Fix undefined behaviour in gc

2015-10-23T07:51:06+00:00

Upstream-Status: Backport Fixes undefined behaviour in boehm GC used by cacao-initial-native as suggested at https://github.com/ivmai/bdwgc/commit/16780405c899f01119bc45167122b4242f6b34fb. The undefined behaviour at very least causes a segmentation fault during classpath-native configure step with Fedora 22. Signed-off-by: Erkka Kääriä Signed-off-by: Maxin B. John