This is expected behavior. ‘-isystem’ places our boost ahead of system boost so our boost is found first. ‘-I’ places our after so you get system boost. It’s possible that if we’re using a boost header that’s missing from our boost then it gets picked up from system boost which could explain that weird Ubuntu failure!
You can use -I to override a system header file, substituting your own version, since these directories are searched before the standard system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files; use -isystem for that.
I interpreted our use of libraries as “vendor-supplied system header files.” But I think the thing that’s really misleading is that there’s no indication in the documentation that the include order should change by using -I or -isystem.
Add the directory dir to the head of the list of directories to be searched for header files. This can be used to override a system header file, substituting your own version, since these directories are searched before the system header file directories. However, you should not use this option to add directories that contain vendor-supplied system header files (use -isystem for that). If you use more than one -I option, the directories are scanned in left-to-right order; the standard system directories come after.
If a standard system include directory, or a directory specified with -isystem, is also specified with -I, the -I option will be ignored. The directory will still be searched but as a system directory at its normal position in the system include chain. This is to ensure that GCC’s procedure to fix buggy system headers and the ordering for the include_next directive are not inadvertently changed. If you really need to change the search order for system directories, use the -nostdinc and/or -isystem options.
I think by vendor-supplied they mean your distribution supplied them?
I guess we probably do want to override any locally installed boosts, right? Though I’ve seen people ask for the opposite sometimes, they can set that in make/local with BOOST= I believe. So it sounds like we should try switching to -I and just pray that we don’t inherit compiler warnings (or maybe change the stance on that / figure out other ways to suppress them?).
The gcc man page (at least on arch linux) is informative about how this all works, search for -isystem and (gah) -idirafter
Yeah, I got that wrong, it really looks like we should be using -I throughout and possibly -isysroot if things get really hairy. I’d look into this but I have two other Stan things promised already that are getting done first :P
yeah, in general, agree it would be nice to say what we override it with.
I’m still concerned that if our version of Boost is missing a header it will get mixed in from the system install unless we play games with -isysroot… of course playing those games would mean downstream projects need to set their own flags (can’t imagine R’s build system would like that option).
Mind quoting it or finding an online version? That sounds really useful – I’ve never found doc that describes what order things are included.
Yeah, I think we’ll want to use -I
We will inherit compiler warnings. I think we just need to suppress them with compiler options. It sucks, but if we can’t rely on the use of -isystem, then I think that’s a reasonable option. If you figure out a way to selectively suppress warnings, that would be awesome. I’ve never seen it, but maybe there’s a different option that I don’t know about.
Thanks much. The behavior contradicts the documentation.
Here’s the relevant part:
You can specify any number or combination of these options on the command line to search for header files in several directories. 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.
The part that’s wrong is that it sounds like instead of (3, 4, 5), in implementation it’s (3, 5, 4). The -isystem directories are after the standard system directories in the lookup order.
Mind double-checking that I read that doc correctly?
Yeah, you read the doc right, I’d have to do more checking to really understand what order things are happening in for real (in implementation). I don’t think we should worry about the warnings, just capture the compiler output wholesale and go from there. … even in rstan we should be able to do it.