Commit Graph

245 Commits

Author SHA1 Message Date
Julian Dolby b2503628a4 1) a bit more source mappimg information
2) fixes to how Contexts are combined
2018-10-13 08:42:08 -04:00
Manu Sridharan 49628fdf44 Start new development version 2018-08-22 12:01:19 -07:00
Manu Sridharan 6b46ce4faa Version 1.5.0 2018-08-22 11:19:51 -07:00
Ben Liblit a7cef8e77a Declare a task's outputs, enabling incremental build and caching
This specific task runs an external command, and we consider the task
successful if that command exits without error.  We don't actually
examine the stdout or stderr of the command being run.

However, it is still useful to log the stdout and stderr to a file,
and to declare that file to be the output of the task.  Otherwise, the
task has no declared outputs at all.  A task with no outputs is
ineligible for caching and is always considered to be out-of-date.

squash! Declare a task's outputs, enabling incremental build and caching
2018-08-04 04:29:59 -05:00
Leo Li d15f49bd90 Add install_name when build libcast on macos. (#332)
Gradle won't pass absolute path when build libcast. We need to set install_name manually otherwise `dyld` would not able to find libcast at runtime.

This is only needed on macos since `ld` will look up all runtime search path automatically.
2018-07-22 02:42:19 +02:00
Ben Liblit bc3ea1a777 Fix a spelling error in a comment 2018-07-20 08:44:23 +02:00
Ben Liblit 2b2483abd6 Avoid dereferencing null if no C/C++ compiler is present
Fixes #328, which requested better diagnostic messages in the case of
a missing C/C++ compiler toolchain.  Gradle actually has perfectly
good, informative messages in that case.  Unfortunately, we were
killing the build by dereferencing null before Gradle had a chance to
explain.  Now we bail out of some setup work early to avoid the null
dereference, thereby letting Gradle explain things properly.
2018-07-20 08:44:23 +02:00
Ben Liblit 1ac4ca9475 Tweaks and instructions for WALA as an IntelliJ IDEA project
We already had some IntelliJ IDEA project metadata files in ".idea".
I've revisited and updated those now that I have more experience with
Gradle + IntelliJ IDEA + Git.  I think this now represents a better
set of decisions regarding what does and does not belong in version
control.

This commit also extends "README-Gradle.md" with clear instructions on
how to bringup WALA as a top-level IntelliJ IDEA project.  The
instructions are of a similar flavor to the Eclipse instructions that
were already present, though the details vary.  Most notably, with
IntelliJ IDEA you should *open* WALA as an existing project,
not *import* it as a new Gradle project derived from "build.gradle".
This is exactly the reverse of what one should and shouldn't do for
WALA in Eclipse.
2018-07-12 14:52:13 -07:00
Ben Liblit 3d9e4d23d8 Add helper task for extra setup after opening in IntelliJ IDEA
This task serves a similar role to the "afterEclipseBuildshipImport"
task used with Eclipse.  It should only be necessary to build this
task once:  in a freshly checked-out tree, just after opening it for
the first time in IntelliJ IDEA.

Ideally this extra setup task would be triggered automatically using
the "Tasks Activation" feature of IntelliJ IDEA's Gradle support.
Unfortunately, "Tasks Activation" settings are recorded in
".idea/workspace.xml", which is used for non-revision-tracked personal
settings.
2018-07-11 15:13:39 -05:00
Julian Dolby b1b09684bd
Merge pull request #317 from liblit/future-java-compatibility-fixes
Future Java compatibility fixes
2018-06-06 12:52:51 -04:00
Ben Liblit 5336a08af2 Avoid using deprecated boxing constructors
Boxing a primitive using the constructor ("new Integer(4)") always
creates a distinct new boxed instance.  That's rarely what you need,
and in fact all of those constructors have been deprecated in Java 9.
Using the static "valueOf" method instead ("Integer.valueOf(4)") can
give better performance by reusing existing instances.  You no longer
get a unique boxed object, but generally that's OK.
2018-06-05 14:44:59 -05:00
Julian Dolby 9aed4e058d more tracking of sourse positions for function parameters 2018-06-05 15:00:31 -04:00
Ben Liblit 5cf8b7efe3 Stop using deprecated "javah" to generate JNI headers
"javah" was deprecated in Java 9, and has been removed entirely in
Java 10.  The right way to generate headers now is by using the "-h"
flag to "javac".  When "javac" is run in this way, it still generates
bytecode too.  So ideally, we'd run "javac" just once to generate
bytecode and headers simultaneously.  Fortunately, the Gradle JNI
plugin at <https://github.com/wpilibsuite/gradle-jni> help us do this
cleanly.  Nice!
2018-06-04 12:29:57 -05:00
Ben Liblit 6679262707 Refactor linker logic, and add "smoke_main" to automated tests
Previously we were compiling and linking "smoke_main", but not
actually running it as part of automated testing.  I simply overlooked
this in the process of recreating the Maven build logic in Gradle.
Now we run "smoke_main" when testing, which turns out to be a pretty
good test of our management of both Java search paths as well as
linker / shared library search paths.
2018-06-04 12:28:42 -05:00
Ben Liblit c7344e611a Remove TODO comment about producing native components for test only
According to
<https://docs.gradle.org/current/userguide/native_software.html>,
"When you assemble dependents of a component, the component and all of
its dependents are compiled and linked, including any test suite
binaries."  So it's intentional that the "assemble" task causes
creation of the smoke_main executable and xlator_test shared library.
Nothing TODO here; the current behavior is as designed.
2018-06-04 12:28:42 -05:00
Ben Liblit 2067d6c37a Open up some more vertical white space 2018-06-04 12:28:42 -05:00
Ben Liblit e2ce6a84b0 Load plugins using "plugins" closure rather than "apply plugin"
Apparently the latter is considered a "legacy method":
<https://docs.gradle.org/current/userguide/plugins.html#sec:old_plugin_application>.
2018-05-23 16:47:58 -05:00
Ben Liblit decd164fa6 Require JUnit 4.12 instead of 4.11
WALA itself does not use any JUnit 4.12 features.  However, I am
working on a WALA-based project that does require JUnit 4.12.  Mixing
jar versions is a path to madness.  So if the WALA maintainers don't
mind, it would make my life easier if WALA itself required JUnit 4.12.
Otherwise, I need to maintain that 4.11/4.12 difference indefinitely
as a divergence between official WALA and my WALA variant.

I suppose an alternative could be to let the JUnit version be
specified externally somehow. I have not explored this option in
depth, but could look into it if simply moving to JUnit 4.12 is
undesirable.
2018-05-21 17:27:54 -05:00
Julian Dolby 27a8fff714 ast-based constant folding 2018-04-28 12:05:49 +02:00
Ben Liblit 8e27f98f2d Upgrade Gradle wrapper to release 4.7
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.
2018-04-18 19:32:04 -05:00
Ben Liblit 209086f068 Bump version to 1.5.0-SNAPSHOT before merging with WALA master
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.
2018-04-18 11:29:29 -05:00
Ben Liblit 4840966807 Don't try to exhaustively anticipate all generated header names
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.
2018-04-18 11:29:29 -05:00
Ben Liblit 74523f5058 Enable caching of task outputs for custom build tasks 2018-04-18 11:29:29 -05:00
Ben Liblit c6a6ef8b97 Minor indentation fix 2018-04-18 11:29:28 -05:00
Ben Liblit bcbd298808 Extra help for finding "cast" native library on macOS
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.
2018-04-18 11:29:28 -05:00
Ben Liblit a99db6b946 Trivial whitespace tweak 2018-04-18 11:29:28 -05:00
Ben Liblit 01e54886df Exclude one macOS test that I don't know how to fix right now 2018-04-18 11:29:28 -05:00
Ben Liblit 5398570308 Update Eclipse JUnit test launchers for use with Buildship
Previously Buildship removed its classpath from all of these
launchers.  Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog.  Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these.  I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
2018-04-18 11:29:27 -05:00
Ben Liblit 50bed1cbe8 Compute a library path from the corresponding linker task
Previously we were repeating the library path twice, but that's not
good for long-term maintenance.
2018-04-18 11:29:27 -05:00
Ben Liblit 22421c6882 rpath only matters for shared libraries 2018-04-18 11:29:27 -05:00
Ben Liblit 7c4c2c895c Add previously-undeclared dependency of tests on native library 2018-04-18 11:29:27 -05:00
Ben Liblit 98324cd148 Simplify how we refer to existing tasks 2018-04-18 11:29:26 -05:00
Ben Liblit 01acd0e338 RPath settings apply only to Linux; some only to Linux on x86_64
I don't know whether Windows or MacOS needs anything similar.  If they
do, the details will differ, and should be handled by adding suitable
cases to these switch statements.
2018-04-18 11:29:26 -05:00
Ben Liblit 1e1de1bdb9 Prefer single-quoted (non-interpolated) strings where sufficient 2018-04-18 11:29:26 -05:00
Ben Liblit dd1f51e8f0 Buildship removed classpath provider thing from all launch configs
This consistently happens when I import WALA as an existing Gradle
project into Eclipse with Buildship.  I don't really know what this
change means, or whether it's desirable.  For now, I'm going to trust
Buildship and see what happens.
2018-04-18 11:29:25 -05:00
Ben Liblit ba5849afb6 Simplify inclusion of "OSGI-INF" and the only file it contains 2018-04-18 11:29:25 -05:00
Ben Liblit 6bcca003a2 Tweak output dirs to match what Buildship puts into ".classpath" 2018-04-18 11:29:25 -05:00
Ben Liblit 89860b53bb Let Buildship create new settings files when importing
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control.  Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
2018-04-18 11:29:25 -05:00
Ben Liblit 4b48f8ee4d Have Buildship add Eclipse plugin (PDE) nature to some subprojects
Specifically, we need this for subprojects that build included plugins
for any of the "*_feature" subprojects.
2018-04-18 11:29:25 -05:00
Ben Liblit 310ef1daa5 Exclude Eclipse ".project" and ".classpath" from version control
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
2018-04-18 11:29:25 -05:00
Ben Liblit 3ce242a22c Simplify loading of plugins shared by many subprojects 2018-04-18 11:29:25 -05:00
Ben Liblit 1432e18c37 Clean up some simple syntactic redundancy in dependency declarations 2018-04-18 11:29:25 -05:00
Ben Liblit 3d973e9d61 Find the "xlator_test" shared library at test run time
Dependencies are still not set properly here, so you need to have
built the shared library ("./gradlew xlator_testSharedLibrary") before
running the ":com.ibm.wala.cast.test:test" test task.  But at least
the tests do now find and load that shared library properly.
2018-04-18 11:29:25 -05:00
Ben Liblit 5d5fa18b5f Replace source directories rather than appending to them
I was confused about the differences among:

	srcDir 'foo'
	srcDirs ['foo']
	srcDirs = ['foo']

As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely.  I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
2018-04-18 11:29:25 -05:00
Ben Liblit 0704a66ab1 Cleaner way to form colon-deliminated search path from list of paths 2018-04-18 11:29:25 -05:00
Ben Liblit e52c8d981d Declare common library dependencies for source sets, not binaries
No sense repeating this for each binary when it's the same for all of
them.
2018-04-18 11:29:25 -05:00
Ben Liblit b9e712bfa9 Add a second native library and a native executable 2018-04-18 11:29:25 -05:00
Ben Liblit afa982adf2 Properly distinguish main from test code, now that I know how 2018-04-18 11:29:25 -05:00
Ben Liblit 530d74929f Many improvements to Gradle build support, including within Eclipse 2018-04-18 11:29:24 -05:00
Sungho Lee 50d0f7ee71 Change build.gradle files for proper format and delete all tests 2018-04-18 11:29:24 -05:00