Summary:
Saw these two types of errors before (but they're hard to reproduce locally) when building the models:
- `ERROR: Zip.Error("/mnt/btrfs/trunk-git-infer-739-1503054473/infer/bin/../lib/java/models.jar", "", "end of central directory not found, not a ZIP file")`. I think this means infer reads a partially-written models jar. We shouldn't try to load this in models mode.
- `install` would complain that the destination already exists. I think this can only happen if there's a race and the file gets created between when install first checks and when it tries to write to it.
This made me realise that the some of the models are computed in C and C++ mode
and we pick one computed spec arbitrarily. That sounds a bit dodgy but at least
now we do so in a non-racy way.
Reviewed By: jeremydubreil
Differential Revision: D5658389
fbshipit-source-id: 8077279
Summary:
It can be useful when debugging infer or the Makefiles themselves to see what
`make` is doing. Instead of editing Makefiles to remove `@` now you can `make
VERBOSE=1`.
This is just `git ls-files | grep -e Makefile -e '.*\.make' | xargs sed -e 's/^\t@/\t$(QUIET)/' -i`, and adding the definition of `QUIET` to Makefile.config.
Reviewed By: jeremydubreil
Differential Revision: D4779115
fbshipit-source-id: e6e4642
Summary:
This makes sure that one can run `./build-infer.sh` then `make`. Otherwise it's
not always clear what one should do to recompile infer, eg when `make` will
work and when `./build-infer.sh` should be used instead, in particular when the
user doesn't have opam configured for her terminal.
Reviewed By: jberdine
Differential Revision: D4698159
fbshipit-source-id: 5df8059
Summary:
This is helpful to make sure tests are up to date wrt the models.
Also made the Java deps depend on the models.jar instead of the model sources
as that's what the tests will be using. In particular, updating the sources of
the models will not update the results of a test unless someone rebuilds
models.jar, so rerunning the tests when the models haven't been rebuilt is
useless.
Reviewed By: akotulski
Differential Revision: D4635129
fbshipit-source-id: 75b4ab6
Summary:
Turns this was needed only because we want infer-out to be models/infer.
Passing `--buck` together with passing `-d models` to `javac` was achieving the
same thing in a more roundabout way.
Reviewed By: jeremydubreil
Differential Revision: D4423185
fbshipit-source-id: 7cafe3b
Summary: Need to upgrade in order to specify some taint properties on a more recent `WebView` API.
Reviewed By: cristianoc
Differential Revision: D4382590
fbshipit-source-id: 0925742
Summary: Using multicore introduces some flakiness when building the models. This leads to summries for the models that are not always the same after rebuidling from scratch.
Reviewed By: jberdine
Differential Revision: D4306468
fbshipit-source-id: 96933d6
Summary:
`install` will not do anything if the file didn't change, which should give
`make` more opportunities to not do work.
Reviewed By: jeremydubreil
Differential Revision: D4161918
fbshipit-source-id: 9b9061a
Summary:
Config.analyze_models, set by the INFER_ANALYZE_MODELS environment
variable, is redundant with Config.models_mode.
Reviewed By: jvillard
Differential Revision: D4047338
fbshipit-source-id: 4522d65
Summary: The Infer builtins can be used in the e2e tests, but those tests should not depend on the Infer models to avoid cyclic dependencies. This diff separates the models and the Infer builtins in two directories so that the test can depend on the builtins without depending on the models
Reviewed By: sblackshear
Differential Revision: D3929478
fbshipit-source-id: 7d0ab79
Summary:
Hardcoding `variable@` in Makefiles is Bad™ because it prevents the users from
overwriting them easily with `make variable="my custom value"`. The right way
to do it is thus:
```
variable = variable@
# then use $(variable) everywhere
```
This diff puts all the `variable = variable@` lines in Makefile.config.in, and
changes every occurrence of a `variable@` to `$(variable)` everywhere else.
I mostly automated generating this diff. Here are the steps I did:
- find out which `variable@`s we use:
find . -name 'Makefile*' -exec grep -e '@[^@ []\+@' -o -h \{\} \+ | sort | uniq > config_variables
- write this `replace.sh` script to replace every `variable@` with `$(variable)`:
```
#!/bin/sh
config_vars_file=$1
shift
for line in $(cat $config_vars_file); do
var=$(echo $line | tr -d @)
sed -i -e "s/$line/\$($var)/g" $@ > /dev/null
done
```
- run the script as such:
find . -name 'Makefile.*in' \( -not -wholename './Makefile.config.in' \) -exec ./replace.sh config_variables \{\} \+
- put all the `VARIABLE = VARIABLE@` lines in Makefile.config.in
- move all `Makefile.in` to `Makefile`, since they don't need to be generated by `./configure` anymore:
```
for i in $(find . -name 'Makefile.*in' \( -not -wholename './Makefile.config.in' \)); do \
rm $(dirname $i)/$(basename $i .in) && git mv $i $(dirname $i)/$(basename $i .in) ; \
done
```
- delete all Makefile except Makefile.config from configure.ac
- manually inspect and remove remaining instances of `VAR = $(VAR)` in makefiles, looking at the output of `git grep '^\(\w\+\) = $(\1)'`
Reviewed By: jberdine
Differential Revision: D3358379
fbshipit-source-id: 5d37f02
Summary:
public
Use autoconf's detection of xcode-select to decide whether to build the ObjC
models or not.
Reviewed By: jeremydubreil
Differential Revision: D2703864
fb-gh-sync-id: e6dadca
Jules Villard
Jeremy Dubreil
Sam Blackshear
Josh Berdine
Open Source Synchronization