Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Spec compiler_flags duplicated and not overwritten #1895

Open
valerius opened this Issue · 5 comments

4 participants

@valerius

I'm really excited about incorporating CocoaPods into my development process but have run into an issue. It would appear that a child spec may append compiler options to its parent spec, but cannot override them. Here is an example:

  s.subspec 'clucene' do |sna|
    sna.requires_arc = false
    sna.source_files = "#{base_lib_dir}/clucene/src/**/*.{h,m,mm,c,cpp}"
    sna.exclude_files = "#{base_lib_dir}/clucene/src/demo/**/*.{h,m,mm,c,cpp}" ,"#{base_lib_dir}/clucene/src/CLucene/CLMonolithic.cpp"
    sna.header_mappings_dir = "#{base_lib_dir}/clucene/src"
    sna.compiler_flags= '-stdlib=libstdc++','-std=c++98'
  end

However, the compile options generated are:

# See 2nd and last line
clang -x c++-header -arch armv7 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 

-std=gnu++11 -stdlib=libc++  # The compiler flags added by the parent

-fmodules -fmodules-cache-path=/var/folders/6s/ldhp04d96fg_1v8qb_fvkp500000gn/C/com.apple.DeveloperTools/5.0.2-5A3005/Xcode/ModuleCache -Wno-trigraphs 
-fpascal-strings -Os -Wno-missing-field-initializers -Wno-missing-prototypes -Werror=return-type -Werror=deprecated-objc-isa-usage -Werror=objc-root-class 
-Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time-destructors -Wno-missing-braces -Wparentheses -Wswitch -Wunused-function -Wno-unused-label 
-Wno-unused-parameter -Wunused-variable -Wunused-value -Wempty-body -Wuninitialized -Wno-unknown-pragmas -Wno-shadow -Wno-four-char-constants -Wno-conversion
 -Wconstant-conversion -Wint-conversion -Wbool-conversion -Wenum-conversion -Wshorten-64-to-32 -Wno-newline-eof -Wno-c++11-extensions -DCOCOAPODS=1 
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk -fstrict-aliasing -Wdeprecated-declarations
 -Winvalid-offsetof -g -Wno-sign-conversion -miphoneos-version-min=7.0 -iquote /tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/Pods-MyProject-generated-files.hmap 
-I/tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/Pods-MyProject-own-target-headers.hmap
-I/tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/Pods-MyProject-all-target-headers.hmap -iquote /tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/Pods-MyProject-project-headers.hmap -I/tmp/CocoaPods/Lint/Pods/build/Release-iphoneos/include -I/tmp/CocoaPods/Lint/Pods/BuildHeaders -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/analysis
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/analysis/standard -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/config
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/debug -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/document
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/index -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/queryParser
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/search -I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/store
-I/tmp/CocoaPods/Lint/Pods/BuildHeaders/MyProject/CLucene/util -I/tmp/CocoaPods/Lint/Pods/Headers -I/tmp/CocoaPods/Lint/Pods/Headers/ASIHTTPRequest
-I/tmp/CocoaPods/Lint/Pods/Headers/DACircularProgress -I/tmp/CocoaPods/Lint/Pods/Headers/FMDB -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/analysis -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/analysis/standard -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/config 
-I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/debug -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/document 
-I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/index -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/queryParser 
-I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/search -I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/store
-I/tmp/CocoaPods/Lint/Pods/Headers/MyProject/CLucene/util -I/tmp/CocoaPods/Lint/Pods/Headers/InAppSettingsKit
-I/tmp/CocoaPods/Lint/Pods/Headers/JSMessagesViewController -I/tmp/CocoaPods/Lint/Pods/Headers/JSONKit-NoWarning 
-I/tmp/CocoaPods/Lint/Pods/Headers/JSQSystemSoundPlayer -I/tmp/CocoaPods/Lint/Pods/Headers/MBProgressHUD -I/tmp/CocoaPods/Lint/Pods/Headers/MKStoreKit 
-I/tmp/CocoaPods/Lint/Pods/Headers/MSDynamicsDrawerViewController -I/tmp/CocoaPods/Lint/Pods/Headers/MWPhotoBrowser -I/tmp/CocoaPods/Lint/Pods/Headers/OHAttributedLabel 
-I/tmp/CocoaPods/Lint/Pods/Headers/PSTCollectionView -I/tmp/CocoaPods/Lint/Pods/Headers/Reachability -I/tmp/CocoaPods/Lint/Pods/Headers/RegexKitLite -I/tmp/CocoaPods/Lint/Pods/Headers/SDWebImage
 -I/tmp/CocoaPods/Lint/Pods/Headers/URBSegmentedControl -I/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/include/libxml2 
-I/tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/DerivedSources/armv7 -I/tmp/CocoaPods/Lint/Pods/build/Pods.build/Release-iphoneos/Pods-MyProject.build/DerivedSources
-F/tmp/CocoaPods/Lint/Pods/build/Release-iphoneos -DNS_BLOCK_ASSERTIONS=1 -DNS_BLOCK_ASSERTIONS=1

-stdlib=libstdc++ -std=c++98  # This compiler flags I added in the sub spec
…

@fabiopelosin

Indeed, this is not a supported feature. Did you investigate the usage of two different subspecs?

@valerius

Yup, therein lies the issue. Unless I misunderstand why you mean by two different suspects, the example provided is how they were utilized (though the others are omitted). I personally believe instead of the 'flags' just being a list which is appended to, as it appears the case in Cocapods... perhaps those array items could be parsed into a hash, such that -stdlib is a key, which is overridden in a suspect, etc. Thus:

compiler_flags = "-std=c++98"
# equates to after parsing =
compiler_flags ={ :std=>"c++98"}

Anyways, thats my two cent without diving too much in the code. Personally however, per documentation that would seem like a bug IMHO, and therefore should not be closed even if it can't be fixed until re-architected. As if you were to apply such compiler flags to a specific target in a project, or to a included dependency, there would not be duplicate arguments but only those provided by the configuration, etc. Nevertheless, it's still a great tool, I guess I just can't rely on that option as I will never have control over what my flags are opened to, thus mooted by. Thanks.

@fabiopelosin

I see your point and there has been some related discussion about this in the past.

@fabiopelosin fabiopelosin reopened this
@CocoaPodsBot CocoaPodsBot was unassigned by valerius
@CocoaPodsBot
Collaborator

Issue has been confirmed by @neonichu

@CocoaPodsBot CocoaPodsBot was unassigned by valerius
@segiddins
Owner

I don't know that we want to start trying to parse compiler flags -- that's a dark route to go down. I'm all for just documenting the current behavior and calling that a day.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.