Closed hons82 closed 9 years ago
Strange... on our machines here in the company it works everywhere... With $SDKROOT
we had some problems... but not on all machines
Oh, I'm using OSX El Capitan already, forgot about it :)
Well, this is still a bash - it shouldn't be a big deal to check if file exists?
Hey, does one of you guys want to have collaborator access to this repo? I'm a bit busy right now and I'm not using this library that actively. It would be probably a good idea to merge the pull requests and the 'xpath-fix' branch into the master branch. I just didn't have the time to verify them and to make sure that nothing breaks.
@graetzer I would like to have a collaborator access as I'm still hardly rely on XML parsing (gosh, it's 2015 already, what I'm doing with my life...)
Alright I added you as a collaborator. Just make sure that if you add the stuff from the 'xpath-fix' branch that it won't break the code of existing library-users. I'm not sure if anybody does realistically rely on the broken functionality, but in any case we should at least document it or think of a better solution
Thanks, I will do it gently :)
@hons82 Could you please check once again that $(SDKROOT)
prefix doesn't work? Because in the existing podspec we already have a reference to that path:
s.xcconfig = { "HEADER_SEARCH_PATHS" => "$(SDKROOT)/usr/include/libxml2" }
And there could be multiple different SDK on the same machine, so I guess we have to go with this prefix.
UPD: Got a remote connection to different OSX (using browserstack.com machines):
OS X El Capitan - folder doesn't exists OS X Yosemite - folder doesn't exists OS X Lion - folder /usr/include/libxml2/libxml exists
Hi, we've been using it here by adding the files directly, actually because we couldn't update this repository at that time. On my machine (El Capitan/xcode7) It is working with ${SDKROOT}
and I think it makes sense. Somehow I'm able to run it without it too on my machine/devices, but it might be some leftover from previous trials, because on my co-workers freshly installed machine it is just working with your config.
So I'd go for yours. Once it is available on Cocoapods we'll try it with picokit
Good, thanks! I accept it and add SDKROOT then!
Hey, if you need me to publish a new version to CocoaPods at some point, just shoot me an email.
I have a plan to merge and check xpath-fix branch this weekend. Afterwards - I'll tell, thanks
Ready for release. With this commit https://github.com/graetzer/GDataXML-HTML/commit/7cea66b36c6b653c878db572dfa417464c1a637c I've added test project with unit tests and travis configuration file.
It would be cool if you would enable travis for this repo (just visit travis-ci.org, login with GitHub and enable Travis for this repo).
I enabled travis, should we increase the version number to 1.2.1 or 1.3 ?
1.3 maybe? Considering this pull request + xpath I guess we can bump minor version to 1.3
Hm, the travis test is failing https://travis-ci.org/graetzer/GDataXML-HTML/builds/83530716
Yep, fixed. Thanks for the release!
@graetzer Could you release 1.3.0 a new version to cocoapods? It's 1.2.0 still. Thx
@graetzer @artemyarulin - just checking on a new cocoapods release; are you up for doing one soon? Thanks!
Well, 1.3.0 already released https://github.com/CocoaPods/Specs/blob/master/Specs/GDataXML-HTML/1.3.0/GDataXML-HTML.podspec.json
And it includes module map changes already https://github.com/CocoaPods/Specs/blob/master/Specs/GDataXML-HTML/1.3.0/GDataXML-HTML.podspec.json#L21-L22
Do you have still some problems @precipice ?
@artemyarulin Oh, whoops! Thanks much, I appreciate the pointers. I have a warning to resolve but it looks like the problem is on my side.
I've added the necessary declarations to create a modulemap for libxml. Which is solving this problem for your library. With this you'll be able to use it in a framework using swift