----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/59625/#review177307 -----------------------------------------------------------
I did not explicitly call out that this change leads to suppression of diagnostics from all headers found via the modified includes; AFAICT this changed behavior is OK. An alternative approach could be to e.g., surround includes from Boost with pragmas suppression the diagnostics, and change adding of Boost prefixes from `-isystem` to `-I`. - Benjamin Bannier On June 8, 2017, 3: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, 3: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 > >
