This follows an IntelliJ IDEA recommendation. Having the full
distribution allows IntelliJ IDEA to provide contextual help,
autocompletion, etc. for Gradle build scripts. The disadvantage, I
suppose, is that it imposes a larger download time on first use of
"gradlew".
New features that I like from this release: (1) better output grouping
when building in parallel, and (2) automatic test ordering to try
previously-failing tests first.
This gives the WALA maintainers the option of doing future 1.4.5+
releases from of a pre-Gradle branch if these merged Gradle changes
turn out to be more disruptive than expected.
The Eclipse metadata files created in this way are not identical to
those that Buildship would create when importing into Eclipse. The
tests in com.ibm.wala.cast.java.test.JDTJava15IRTests and
com.ibm.wala.cast.java.test.JDTJavaIRTests seem to pass using either
the Gradle-generated or the Buildship-generated versions.
As an aside, if you generate these files using Gradle first and *then*
import using Buildship, you end up with metadata that is identical to
what you would have had if you'd only imported with
Buildship. (There's one irrelevant difference in an unimportant
"<comment>" element.) So Maven's tests should run fine under any
wacky mix of Gradle- and Buildship-generated Eclipse metadata files.
That being said, I recommend not mixing build systems. WALA can be
built using either Maven, Gradle, or Eclipse+Buildship, but you're
probably better off only using one of these in any given build tree.
A mixed tree *should* probably work, but I haven't tested it
thoroughly, and consider better to avoid doing.
Incidentally, if there are other Maven-preparation steps that we'd
like Gradle to automate for us, that can now be done easily by
creating more "prepareMavenBuild" Gradle tasks in other subprojects
and adding the appropriate dependencies. For example, it would be
trivial to use this to automate downloading "/tmp/DroidBench",
installing the Android SDK, etc.
I don't know what changes are triggering this. Presumably it's
something to do with the temporary-file code, but I don't see why that
would happen. For now, let's just skip this test.
If multiple tests both write to "/tmp/cg.txt" (for example), then
these tests cannot safely run concurrently. That never used to be a
problem with Maven, since our Maven tests were all strictly sequential
anyway. But parallelized testing using Gradle requires that we do
better. Fortunately, Java has perfectly reasonable APIs for
generating uniquely-named temporary files and directories.
The performance improvement offered by the build cache is modest when
run by Travis CI. This is probably because Travis CI does not keep
the cache on any local machine. Instead, Travis CI uploads the build
cache across a network at the end of each run, then restores the cache
across the network at the start of the next run. So in many cases
we're simply trading network access to original downloads for network
access to the cache image.
Furthermore, it's probably a better test to perform Travis CI testing
jobs from something closer to a clean slate. We really want to know
whether everything builds and passes tests correctly starting from
nothing. We don't want to risk accidentally thinking something would
work simply because we have a cached copy of what it did when it
worked previously.
Previously we unpacked in one task, then installed two extra
components in two dependent tasks. However, installing extra
components modifies some files in place, effectively making those
files both inputs and outputs. That creates race conditions, and
probably interferes with task output caching. Better, then, to treat
the unpack and extra installations all as a single task whose output
is the complete Android SDK tree with all required components
installed.
This should give us a nice build-performance boost, both locally and
in Travis CI. I've used parallel builds routinely for months now, and
they're working fine. Build output caching is newer, but it also
seems to be working well and saves us tremendous time on downloads.
Without this setting, Gradle would run multiple "test" tasks from
multiple subprojects concurrently, but each "test" task would only run
a single test at a time. Some of our subprojects' test tasks take a
long time to complete, which could easily leave us sequentially
testing on just one or two CPU cores while other cores sit idle.
With this change, Gradle will use as many task slots as are
available (e.g., when run with "--parallel") to run multiple
simultaneous JUnit test classes within any given subproject. This
seems to be fine for us: I am unaware of any shared global state that
would cause conflicts between two test classes within any given
subproject.
When JNI headers for a given class, each nested class will end up with
its own additional header. But I don't want to try to parse nested
class details out of the Java source files just so we can determine
exactly which headers will be created. Instead, simply treat the
entire header destination directory as the output of this task.
This task has an input named "hello_hash.ml", and an output named
"hello_hash.jar". So calling this task "generateHelloHash" is too
vague. Now we call it "generateHelloHashJar" instead.
These manifest files are here for use by the Maven build, but Eclipse
is now using Gradle (via Buildship). So the manifests as seen by
Eclipse do not entirely make sense. I'm hesitant to change the
manifests directly, since presumably they were correct for Maven and
still are.
Perhaps some day we'll be using Gradle to generate manifests. Until
that day comes, we're better off leaving the manifests as they are and
just suppressing Eclipse's warnings instead.
This still doesn't actually work, but it's closer than it was before.
There's still some problem with improper mixing of 32-bit ("x86") and
64-bit ("x64") libraries.
Avoid allocating memory using strdup() and then releasing it using
operator delete. strdup()-allocated memory should be released using
free(), not delete. But in these specific cases, there really was
never any good reason to duplicate the C-style strings in the first
place. Instead, we can safely pass those NUL-terminated char pointers
directly in calls to JNI's NewStringUTF(). NewStringUTF() does not
take ownership of its argument, but rather clones that string data
internally before returning. So using strdup() and delete was just
unnecessary memory churn.
In cases where we need to format, concatenate, or construct new
strings, don't use sprintf() into variable-sized, stack-allocated
arrays. Variable-sized arrays are not portable, and in particular are
rejected by Microsoft's Visual Studio 2017 C++ compiler. Instead, do
our string formatting and manipulations using std::ostringstream
and/or std::string. We just need to be a bit careful about the
lifetimes and ownership responsibilities of allocated data. In
brief, (1) ostringstream::str() returns a temporary string instance
that expires at the end of the enclosing statement, independent of the
lifetime of the ostringstream instance; while (2) string::c_str()
returns an pointer to internal data that remains valid as long as the
string on which it was called is valid and unmodified.
The default location of DroidBench in "/tmp/DroidBench" does not work
well on Windows. So let's disable these tests until someone has time to
make that path more portable.
This URL skips over a redirect that the previous URL went through.
This URL also avoids an annoying "Invalid cookie header" warning that
the previous URL produced.
We now download and verify checksums as a single task, rather than as
two separate tasks. This simplifies other task dependencies, since we
no longer have a checksum-verified "stamp" file separate from the
download itself. Unfortunately the combined task now has a
significant amount of repeated boilerplate. I'm hoping to refactor
that all out into a custom task class, but haven't yet figured out the
details:
<https://github.com/michel-kraemer/gradle-download-task/issues/108>.
We now also use ETags to be smarter about when a fresh download is or
is not actually needed. I think there are still opportunities for
improved caching here, but this is a step in the right direction.
I believe Travis CI jobs get two CPUs by default.
Doing parallel builds regularly is also a good way to help us discover
any build race conditions we may have. There's no guarantee that any
such races will be revealed, but even exposing them
nondeterministically is better than having no possibility of exposing
them at all.
We used to use these to find various Eclipse packages, but that was
always a dodgy affair since we never quite knew whether we had
matching versions of everything. Now that we are using the
"com.diffplug.gradle.p2.asmaven" plug-in, though, we have much better
control over getting exactly the Eclipse material we need. These two
Maven repositories no longer provide anything we use, and therefore
can be removed.
Previously this launcher's job was to run "processTestResources" and
any other Gradle tasks needed to create files that Eclipse was
expecting to be available. But we also want to use it to revert the
bad changes that Buildship applies to ".launch" configuration files.
This is a temporary hack to work around
<https://github.com/eclipse/buildship/issues/653>.
Unlike Linux, macOS has no "RPATH" facility for embedding additional
search paths within shared libraries. Instead, we need to set
"DYLD_LIBRARY_PATH" appropriately in the environment. This
environment variable is the macOS analogue of "LD_LIBRARY_PATH" on
Linux.
Note that adding the required path to the "java.library.path" system
property will *not* work. This property only affects where the JVM
looks for shared objects that it is loading directly. This property
does not influence the search for other, transitively-required shared
objects.
Fixes#3.
Ben Liblit
Julian Dolby
Ben Liblit