mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mesos Reviewbot Windows <revi...@mesos.apache.org>
Subject Re: Review Request 59625: Fixed interference of unbundled dependency include paths with Boost.
Date Thu, 08 Jun 2017 13:54:08 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/59625/#review177305
-----------------------------------------------------------



Patch looks great!

Reviews applied: [59625]

Passed command: support\windows-build.bat

- Mesos Reviewbot Windows


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
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message