----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/59625/#review177345 -----------------------------------------------------------
Fix it, then Ship it! Thanks Benjamin! configure.ac Line 717 (original), 718 (patched) <https://reviews.apache.org/r/59625/#comment250904> This one gets too long, fixing while committing. configure.ac Line 817 (original), 824 (patched) <https://reviews.apache.org/r/59625/#comment250901> Not yours, but it is a bit unfortunate that we are switching back and forth between prepending and appending the search path accross the components without any explicit reasoning. Should we unify and fix that as well, maybe in a follow up? - Till Toenshoff On June 8, 2017, 1:14 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/59625/ > ----------------------------------------------------------- > > (Updated June 8, 2017, 1:14 p.m.) > > > Review request for mesos, Michael Park and Till Toenshoff. > > > Bugs: MESOS-7581 > https://issues.apache.org/jira/browse/MESOS-7581 > > > Repository: mesos > > > Description > ------- > > Since some of the contents of Boost headers we include trigger > diagnostics with our compiler setups (e.g., use of 'auto_ptr'), we > include Boost with '-isystem' instead of '-I'. This treats headers > included from such paths as system headers which suppresses all > diagnostics. Other headers we include with '-I'. > > At least GCC performs separate lookups for headers depending on how > their path was specified[1]. > > > The lookup order is as follows: > > > > 1. For the quote form of the include directive, the directory of the > > current file is searched first. > > 2. For the quote form of the include directive, the directories > > specified by '-iquote' options are searched in left-to-right order, > > as they appear on the command line. > > 3. Directories specified with '-I' options are scanned in > > left-to-right order. > > 4. Directories specified with '-isystem' options are scanned in > > left-to-right order. > > 5. Standard system directories are scanned. > > 6. Directories specified with '-idirafter' options are scanned in > > left-to-right order. > > Since we add Boost headers with '-isystem', but other headers with '-I', > building with e.g., unbundled protobuf by specifying > '--with-protobuf=PROTO_PREFIX' causes the build to possibly pick up a > Boost installed in 'PROTO_PREFIX' -- the protobuf include path is > specified with '-I' while the Boost include path is specified with > '-isystem' causes the compiler to first look for Boost headers in the > paths specified with '-I', e.g., the protobuf prefix. > > In order to prevent finding wrong Boost headers, all include paths > possibly containing Boost headers need to be added with the same flag as > the Boost headers itself, i.e., with '-isystem'. This commit adjusts > include path specification for all possibly externally provided > locations, i.e., unbundled third-party dependencies. > > [1]: https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html > > > Diffs > ----- > > configure.ac cf6080e61f5ee3064df98cc4dfb9cca693f3cc68 > > > Diff: https://reviews.apache.org/r/59625/diff/2/ > > > Testing > ------- > > Tested on a number of different Linux and macOS setups in internal CI. > > This e.g., brought to light that some versions do require a space after > `-isystem` for the flag to be recognized, i.e., `-isystem PATH` is valid > while `-isystemPATH` is not recognized. > > > Thanks, > > Benjamin Bannier > >
