RobotLocomotion / drake

Model-based design and verification for robotics.
https://drake.mit.edu
Other
3.33k stars 1.26k forks source link

External dependencies BUILD file do not get loaded in first build attempt #12326

Closed akshitj1 closed 4 years ago

akshitj1 commented 5 years ago

Hi, Till now I have been using drake with cmake installed(drake binary). Now that I had to do some changes in source itself, I tried building from source. But bazel build seems to be breaking.

System Info:

>sw_vers -productVersion
10.15.1
>clang++ -v
Apple clang version 11.0.0 (clang-1100.0.33.8)
>python3 --version
Python 3.7.4
>bazel --version
bazel 1.1.0

Build Command: >bazel build //examples/acrobot:run_lqr

Build failed with error: ERROR: An error occurred during the fetch of repository 'cc': Not a regular file: <bazel_tmp_build_path>/external/local_config_cc/wrapped_clang Upon looking into recent changes in PR I tried to revert back that line to :cc_wrapper.sh This fixed the cc toolchain error, but then fcl library fails:

external/fcl/include/fcl/broadphase/broadphase_SSaP-inl.h:48:38: error: variable cannot be defined in an explicit instantiation; 
if this declaration is meant to be a variable definition, remove the 'template' keyword
class FCL_EXPORT SSaPCollisionManager<double>;

looking up into this error, stumbled upon this link . In comment stated that, FCL_EXPORT may not be defined, but I am not sure how to fix this. I thought that this might be related to first wrapped_clang bug, and might be old compiler issue but that does not seems to be case:

>bazel run //tools/cc_toolchain:print_host_settings`
++ uname -s
+ [[ Darwin == Darwin ]]
++ xcode-select --print-path
+ export DEVELOPER_DIR=/Library/Developer/CommandLineTools
+ DEVELOPER_DIR=/Library/Developer/CommandLineTools
++ xcrun --show-sdk-path
+ export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
+ SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
+ capture_cc_env=tools/cc_toolchain/capture_cc.env
+ source tools/cc_toolchain/capture_cc.env
++ BAZEL_CC=external/local_config_cc/cc_wrapper.sh
++ BAZEL_CC_FLAGS=
+ external/local_config_cc/cc_wrapper.sh --version
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

as it is using llvm 11. Any hint on how I can fix this.

jamiesnape commented 4 years ago

What revision of drake (e.g., git rev-parse HEAD)?

akshitj1 commented 4 years ago

@jamiesnape 5ded94c36d18be43fbcc12b088351188c25c9190

jamiesnape commented 4 years ago

Try the following: Upgrade to Xcode 11.2 and ensure you have run it at least once. Checkout a clean version of drake. Then

$ brew update
$ brew upgrade
$ brew cleanup
$ ./setup/mac/install_prereqs.sh
$ xcode-select --switch /Applications/Xcode.app/Contents/Developer
$ bazel clean --expunge
$ bazel build --subcommands //examples/acrobot:run_lqr

If it fails anywhere, paste the output into a gist and post a link to the gist here.

akshitj1 commented 4 years ago

Hi @jamiesnape , so I thought that xcode command line tools would do just fine as It contains basic macos:SDKs and clang tools. But I was wrong, there is an requirement for entire actual xcode.app. I am still not sure why there is such a heavy dependency(8Gigs) which is majorly IDE and ios devices development SDKs, but anyway now those wrapped_clang errors are gone. Now there is some issue with tinyxml, tinyxml@2. I encountered these 2 separate times after successive clean --expunge,

ERROR: /Volumes/external/repos/drake/multibody/parsing/BUILD.bazel:41:1: undeclared inclusion(s)     in rule '//multibody/parsing:package_map':
this rule is missing dependency declarations for the following files included by 'multibody/parsi    ng/package_map.cc':
 'external/tinyxml2/include/_usr_local_Cellar_tinyxml2_7.1.0_include/tinyxml2.h'
ERROR: /Volumes/external/.cache/bazel/3abb13651c12473ffdebbe1237e5a120/external/sdformat/BUILD.ba    zel:24:1: undeclared inclusion(s) in rule '@sdformat//:urdfdom':
this rule is missing dependency declarations for the following files included by 'external/sdform    at/src/urdf/urdf_parser/urdf_model_state.cpp':
'external/tinyxml/include/_usr_local_opt_tinyxml_include/tinyxml.h'

Both these libararies were installed from install_prereqs.sh. I have reinstalled these but errors persist.

akshitj1 commented 4 years ago

Hi, I am not an avid user of bazel, but are bazel builds known to be indeterministic? This is what I am seeing while trying to debug. Steps to reproduce:

mkdir bar; pushd bar
echo -e "#include<tinyxml.h>\nint main(){return 0;}" > bar.cc
echo "cc_binary(name=\"bar\",srcs=[\"bar.cc\"],deps=[\"@tinyxml\"])" > BUILD.bazel
popd
bazel build //bar:bar --verbose_failures

Initially it gives error:

ERROR: /Volumes/external/repos/drake/bar/BUILD.bazel:1:1: undeclared inclusion(s) in rule '//bar:bar':
this rule is missing dependency declarations for the following files included by 'bar/bar.cc':
  'external/tinyxml/include/_usr_local_opt_tinyxml_include/tinyxml.h'

Which I tried to fix by replacing glob("include/**") to glob('include/**/*.h') in tools/workspace/pkg_config.bzl

This on first run fails with error: gist

While on second(sometimes third) run, the build succeeds??? How is this possible when I haven't changed anything between these successive runs. From what I suspect, the cause might be that in pkg_config.bzl, we are referencing to the files(paths) generated from symlink using glob. While in glob doc it states that:

1. Since glob() runs during BUILD file evaluation, glob() matches files only in your source tree, never generated files.

I am not sure, if symlink paths was meant by while stating generated files but some assumption of execution order(glob after symlink) seems to be breaking here. Can you suggest any workaround, that will let me build for source in any way(build all, run install_external_tools first). Meanwhile, I will look at continuous integration scripts as things are fine there.

akshitj1 commented 4 years ago

I was able to reproduce this issue in ubuntu:bionic with this container. Inspect with bazel aquery 'inputs(".*tinyxml.*", deps(//bar:bar))' to quickly reproduce. First time finds no matching action while finds matches second time. Temporary workaround is to artificially trigger loading phase once with:

bazel aquery 'deps(//examples/acrobot:run_lqr)' > /dev/null
bazel build //examples/acrobot:run_lqr

I think bazel fetch or bazel sync should also do the job. Probably state this in documentation somewhere till fixed. Not sure for a fix, as similar approach is used here: rules_go

jwnimmer-tri commented 4 years ago

I have read the above, but I'm still unclear -- what is the bug in Drake that this issue is trying to highlight? What are the steps to reproduce, the expected results, and the actual result?

akshitj1 commented 4 years ago

I was setting bazel cache path to external drive as I don't have enough space in machine. May be different file system(symlinking capabilities) on external drive could have caused this issue and subsequent reproduction in docker container. Today, freshly built this repo by setting cache path with option --output_user_root on Apple Journal formatted drive. Build was successful in first go without any workarounds. Closing this issue.