Framework distribution

[Forsarion]

@DAlOG @xNekOIx Here is the initial version of framework.

[xNekOIx]

:sunflower:

[dodikk]

Hi, Andrew. A few notes from my side.

1. The library supports both iOS and OS X platforms. However, a framework target has been added for iOS only.
2. The physical layout does not match the framework one. Clients who build the project from source will get compiler errors.

#import <Parus/PVLayout.h> - this header search path will be invalid for the mentioned group of users

1. Some includes of foundation headers are missing
2. PVGroupContext
3. PVGroupImpl
4. PVConstraintContext
5. other "impl" and "context" classes
6. UIKit and AppKit should be added to the *.pch in case you start using them outside "PVUtilities.h"
7. Please use NS_ENUM for better user experience unless backward compatibility prevents you from doing so. By the way, NS_ENUM contents are recognised by the appledoc.

[dodikk]

Only [2] is a critical one

[xNekOIx]

@dodikk headers are not missing. I've moved them to the private area. I've checked it seems to work correct.

[dodikk]

You are subclassing NSObject without specifying #include <Foundation/Foundation.h> which is required.

You are lucky to have no compile time errors due to the order in *.pch file. This only means that precompiled headers are used incorrectly in this project.

[xNekOIx]

@dodikk am I missing something, but Foundation specified in *.pch

[xNekOIx]

@dodikk regarding NS_ENUM, you can't use it with float or double types, you will get an error: non-integral type 'float' is an invalid underlying type see original typedef for layout priorities.

[xNekOIx]

@dodikk regarding UIKit and AppKit: they are already imported with PVUtilities in .pch file. This should be fine. regarding point one: from the documentation of iOS-Universal-Framework#MK8 ...To build the universal version of your framework, you must now use the Archive command rather than the Build command. Build only builds for the current architecture (to speed up compilation when your framework project is a dependency of another project)...

The only thing I suggest to add is a complete compiled framework ready to put in users project. We can place it in root directory. This way user would't need to download code and compile it to get a framework. What do you think?

[xNekOIx]

Universal build doesn't work ( Framework build with current settings doesn't work for OS X :unamused:

[xNekOIx]

should we make two separate targets for iOS framework and OS X framework?

[dodikk]

Foundation specified in *.pch

The only benefit of pre-compiled headers is build speed. Nothing more, nothing less. Do not use _.pch for global visibility. In other words, you should write explicit includes to the foundation whenever you _subclass* its contents. Otherwise you should use forward declarations.

http://gamesfromwithin.com/the-care-and-feeding-of-pre-compiled-headers

---

The simplest way to think of pre-compiled headers is as a cache for header files. The compiler can analyze a set of headers once, compile them, and then have the results ready for any module that needs them.

(from the same article)

[dodikk]

should we make two separate targets for iOS framework and OS X framework?

Yes, you do. Just like you did for the library targets.

[dodikk]

The only thing I suggest to add is a complete compiled framework ready to put in users project. We can place it in root directory. This way user would't need to download code and compile it to get a framework. What do you think?

Your repository will grow too large since binaries are not versioned properly by git. Please compress (gzip) the framework bundle and put it to the releases github page instead.

Another great option is creating a binary cocoa pod. See the podspec example

[dodikk]

regarding NS_ENUM, you can't use it with float or double types,

Please use OBJC_EXTERN const float to declare public constants. The enum keyword has not been designed for such use case.