4bc13b0ec5
1. SKVideoNode is now, partially, available on watchOS and does not require the extra, manual code to swicth selectors depending on the OS version being run. !missing-type! SKVideoNode not bound !missing-selector! SKVideoNode::anchorPoint not bound !missing-selector! SKVideoNode::initWithCoder: not bound !missing-selector! SKVideoNode::initWithFileNamed: not bound !missing-selector! SKVideoNode::initWithURL: not bound !missing-selector! SKVideoNode::setAnchorPoint: not bound !missing-selector! SKVideoNode::setSize: not bound !missing-selector! SKVideoNode::size not bound !missing-selector! +SKVideoNode::videoNodeWithFileNamed: not bound !missing-selector! +SKVideoNode::videoNodeWithURL: not bound 2. SKNodeFocusBehavior is exposed needlessly on watchOS because SpriteKit/Enums.cs was not processed by the generator, so [NoWatch] did not matter. !unknown-native-enum! SKNodeFocusBehavior bound It's also visible on macOS but nothing uses it (so we do not expose it needlessly) !missing-enum! SKNodeFocusBehavior not bound 3. Add missing designated initializer on default `init` !missing-designated-initializer! SKAttributeValue::init is missing an [DesignatedInitializer] attribute !missing-designated-initializer! SKNode::init is missing an [DesignatedInitializer] attribute 4. Remove inconsistency for SKNode subclasses wrt XAMCORE_4_0 The trio attributeValues, setAttributeValues and setValue:forAttributeNamed: that was moved from SKNode (deprecated) into its subclasses. This was done using XAMCORE_4_0 but not on every subclasses. This adds them everywhere to be consistent (only SKNode versions are not defined in XAMCORE_4_0) !missing-selector! SKEffectNode::attributeValues not bound !missing-selector! SKEffectNode::setAttributeValues: not bound !missing-selector! SKEffectNode::setValue:forAttributeNamed: not bound !missing-selector! SKEffectNode::valueForAttributeNamed: not bound !missing-selector! SKEmitterNode::attributeValues not bound !missing-selector! SKEmitterNode::setAttributeValues: not bound !missing-selector! SKEmitterNode::setValue:forAttributeNamed: not bound !missing-selector! SKEmitterNode::valueForAttributeNamed: not bound !missing-selector! SKSpriteNode::attributeValues not bound !missing-selector! SKSpriteNode::setAttributeValues: not bound !missing-selector! SKSpriteNode::setValue:forAttributeNamed: not bound !missing-selector! SKSpriteNode::valueForAttributeNamed: not bound |
||
---|---|---|
.. | ||
.gitignore | ||
DesignatedInitializerCheck.cs | ||
DllImportCheck.cs | ||
EnumCheck.cs | ||
FieldCheck.cs | ||
Helpers.cs | ||
Makefile | ||
ObjCInterfaceCheck.cs | ||
ObjCProtocolCheck.cs | ||
Program.cs | ||
README.md | ||
Runner.cs | ||
SelectorCheck.cs | ||
common.ignore | ||
common.pending | ||
ios.ignore | ||
ios.pending | ||
osx.ignore | ||
osx.pending | ||
packages.config | ||
tvos.ignore | ||
tvos.pending | ||
watchos.ignore | ||
watchos.pending | ||
xtro-sharpie.csproj | ||
xtro-sharpie.sln |
README.md
Extrospection Tests based on ObjectiveSharpie
Goals
- Compare our bindings with the information available Apple's C/ObjC header files
Design
-
The runner visit the provided (managed) assembly first, then it visit the precompiled headers (pch file) for an SDK (e.g. iOS or OSX);
-
Rules can be called at any steps to gather data and or report issues. Rules are also called at the end of the visits;
-
Rules should be kept simple and the external files, e.g.
known-issues
, should be used to track special cases, along with comments with our decisions, i.e. why we tolarate them. That will ease code sharing across existing and new platforms;
Rules
Existing
Those should be good enough to be execute on the bots on each build.
1) classify: takes the output from either 'sharpie' or 'all' (ios.results and osx.results files) classifies them in [ios|osx|common].[ignore|pending|unclassified] files
NOTE: to add an entry to the ignore and pending files, just copy the entire line from the unclassified file into them and add your own comments
(why we are not binding/fixing that? who is going to bind this? etc)
Work In Progress
E.g. rules might be too noisy and require refinement, either in code or in external files.
Ideas
Anything we do not check but for which data is available, e.g.
- NullAllowed;
- Enum member values;
- Generic updates to existing API (need to find a way to avoid braking changes first)
Notes
-
To develop you need a checkout of ObjectiveSharpie
-
clang
is only built for 64bits so you need a 64bits mono to execute the tool. The latest mono versions (required to buildxamarin-macios
supply amono64
binary); -
You can use the
gen-[platform]
orgen-all
target of theMakefile
to generate C# code for all the API from the headers. You can then copy/paste from the (large) files to create the missing bindings;