-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Description
We appear to be mishandling -F, -iframework and -iframeworkwithsysroot compiler arguments, assuming them to be variations of the -framework argument. Rather, these arguments specify where to search for frameworks specified by a -framework argument. These args set up a set of search paths similar to include paths but that apply only to resolving subsequent -framework args on the command line. Also, a -framework argument is intended to be a framework 'name', not a path.
The order of arguments is significant. A -framework preceding a -F does not consider the search path the -F adds. Similarly, if -iframeworkwithsysroot is specified, that applies only to subsequent -framework arg.
It doesn't help that man clang on macOS provides misleading information about -F, associating it specifically with framework include paths (not frameworks themselves), only differing from the description of -I by one word, and not referring to -framework at all.
-I<directory> Add the specified directory to the search path for include files.
-F<directory> Add the specified directory to the search path for framework include files.
Currently, the C/C++ Extension will search directories specified by any of these args (in addition to the default framework paths from a compiler query), for every framework within them, adding all of them to the browse path and IntelliSense configs. It looks like this behavior would be correct, to support sub-frameworks, if applied only to frameworks and not framework search paths.
Most users probably haven't noticed an issue, as this would pick up a superset of frameworks. Though, issues could potentially arise due to IntelliSense picking up headers with conflicting names from incorrect frameworks.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status