search

AliSoftware / OHAttributedLabel

UILabel that supports NSAttributedString
https://github.com/AliSoftware/OHAttributedLabel/wiki
1.51k stars 344 forks source link

OHAttributedLabel integration warning #116

Closed groue closed 11 years ago

groue commented 11 years ago

Hello,

Today, OHAttributedLabel integration can only be done via CocoaPods or project embedding in one's Xcode workspace.

Whenever one does not use CocoaPod, or has no Xcode workspace, and tries to integrate OHAttributedLabel sources right into his project, the missing OHATTRIBUTEDLABEL_DEDICATED_PROJECT macro triggers this warning:

[OHAttributedLabel integration] You should include OHAttributedLabel project in your workspace instead of copying the files in your own app project. See README for instructions.

What about shipping static libraries, or writing clear instructions for building from source?

The comment on top of the warning reads:

// Copying files in your project and thus compiling OHAttributedLabel under different build settings
// than the one provided is not recommended abd increase risks of leaks (ARC vs. MRC) or unwanted behaviors

I wish it was more specific about the "risks". I mean, really specific. So that I do not have to change my build workflow. CocoaPods and workspaces are optional, not mandatory.

What do you think?

AliSoftware commented 11 years ago

Hi,

This is all based on my experience in project integration (in fact I did a presentation in CocoaHeads last week in which I explained it all in details) and detailed in the README instructions and on the wiki.

What about shipping static libraries, or writing clear instructions for building from source?

I already provide detailed instructions on how to integrate the library or how to build it from source, thru the designated workflow that Xcode and Apple officially support and suggest.

Believe me, I have tried all other methods (static library which were at some point missing an architecture or not up-to-date, script phase to lipo the lib, fake fmk solution, etc) on multiple projects thru the latests years, all those methods brings problems at a level or another (problem on #import of the lib headers in Archive stage, or issues when using various configurations, or when using Jenkins-CI, or when using specific compilation settings in an app, and so on) and quickly become a nightmare to maintain (as you can see in my commit history and closed issues on my various libs when I was using any other integration solution).

And last but not least, using a workspace and a dedicated project for the lib is the official recommended way explained by Apple here.

So that I do not have to change my build workflow.

When releasing Xcode4, Apple changed the workflow to manage projects: using Schemes and workspaces instead of just configuration settings and projects. That's how Xcode4 works now, and since more than 2.5 years now…

CocoaPods and workspaces are optional, not mandatory.

CocoaPods and workspaces were maybe optional when using Xcode3. But refusing to using workspaces in Xcode4 will likely bring you integration problems, and I won't be responsible if a library won't compile or won't behave as expected or your app leak or whatever if you don't respect the integration workflow that Xcode4 is expecting. Sure you can keep the old workflow if you really want to insist using old ways, but you will lose a lot of functionality and will risk to encounter problems (dependancies, mixed settings…) that Xcode would otherwise have solved if using the official workflow, and will have to take care for example to add compiler flags for each file individually if you use different build settings, etc

So it's up to you if you want to complicate your workflow by keeping using only one huge xcodeproj and have to maintain integration in all your different environment and manage all the traps yourself. You are free to try it and do so, you do whatever you want. Maybe it will work in your specific configuration, depending on what settings you use and all. Or maybe you will have issues related to that unofficial integration (like dependencies problems, interdependent build settings, memory leaks due to those different build settings, and so on) now or later when your project grows. But if you do, that would be yours to fix.

So that's why it's a #warning, you can try using it another way but there is no warranty that you won't have problems then and I won't help to fix those unofficial solutions used by the users and due to those integration problems if you didn't follow the instructions.

I already had issues and emails from people that had linker errors or compilation issues or runtime problems for example, and spent a lot of time trying to find what was wrong in my code whereas in fact they didn't even follow the README instructions and the problem or leak or whatever issue they had was generated by their own build settings (that turned some compiler features on or off in their application project), not by my code itself. So I won't lose that huge amount of time debugging integration issues now for users that didn't even follow the README instructions. They can decide to ignore the warning and try to integrate OHAttributedLabel another way, but then if they have compilation/linker/behavior issues, it will be theirs to fix.

To be honest, I really wonder why anyone would decide to absolutely NOT use Xcode4 workspaces (especially since the Xcode workflow has now changed since more than 2.5 years and 6 or more Xcode versions). It is the designed solution provided by Apple to integrate external libraries, and has many advantages, like separating compilation settings, warnings and all, and will prevent a lot of integration problems.

So that's quite like if you told me that using boxes to arrange and sort your stuff is not mandatory… sure, but if you keep all your stuff mixed up in a big untidy room and then can't find one object your are looking for, then you will lose a lot of time… Sure if you finally choose to use boxes, at first you will have to tidy the room and organize the boxes once and for all, but you will win a lot of time then.
So here sure you will need to open YourProject.xcworkspace instead of YourProject.xcodeproj in the future, but that's the only thing that will change in your everyday workflow.

groue commented 11 years ago

Thank you for your long and detailed response.

So that's quite like if you told me that using boxes to arrange and sort your stuff is not mandatory…

See ? However defensive is your shipping program, this do not prevent users to open issues :-)

To be honest, I really wonder why anyone would decide to absolutely NOT use Xcode4 workspace

I'll give you two objective reasons, and a subjective one:

AliSoftware commented 11 years ago

See ? However defensive is your shipping program, this do not prevent users to open issues :-)

Sure. But you are free to integrate all your libraries the way you want and ignore the warning. That's why it's only a warning. But if you do ignore it and don't follow the instructions in the README, that's up to you but I then won't provide support for issues you could have related to this.

_For example, if your application does not use ARC and you only copy the OHAttributedLabel files in your application project, those files will then be compiled without ARC, and thus will generate leaks, because OHAttributedLabel was only tested when compiled using ARC (even if I added a lot of security macros to make it as much compatible as possible with non-ARC compilers to have a code as secure as possible, but my Unit Tests and Continuous Integration that does Profiling on leaks and all only test it when compiled with ARC) so if compiled without ARC there may be objects that are not released as they should.

If this occurs because you didn't follow the README instructions and simply copy the files in your app project, that's your responsibility to realize it and fix it, for example by adding -fobjc-arc to all the sources of OHAttributedLabel individually and all. Sure you can do it, no problem. But if you accept the consequences like having to debug your integration issues like mixing ARC and non-ARC code, or activating implicit conversions on some code and not on the other._

That's like if you buy some furniture to assemble yourself. Sure you can try and manage without reading and following the instructions and assemble it your way instead of the recommended way. It will probably work, but if it fall in pieces then, you can't blame the manufacturer. Maybe and probably it will work perfectly, but if it didn't just because you forgot one screw because you didn't follow the instructions or preferred to use a nail, that's your problem then. Or like if you changed some code in my library and then complained that it stopped working, after all.

So do what you want, I never said that you MUST integrate this way. I said that I guaranty it working if you integrate the way I detailed in the README and that it will avoid you a lot of trouble to integrate OHAttributedLabel (and any other library, in fact) in a dedicated project, like Apple recommends, because each library will then be build with the settings it was designed and tested for.

But that's only a warning after all. Do as you please and copy the files if you want, you should not have problems or leaks because I added a lot of protection code to protect against those usages, but even if it is unlikely, if you then do have leaks or other side effects anyway caused by your own specific build settings of your app project that could have side effects on my code, like ARC or implicit conversions or different bridging options, that will be up to you and I can't test and guaranty every single possible situation and build setting combination. So you probably won't have any issues because in the past commits I added a lot of protection code for users that didn't follow the instructions in the past, but if you have, I won't add more nor convert my project from ARC to non-ARC or make it compatible with GCC instead of LLVM or with all compiler options possibilities for that.

groue commented 11 years ago

Thanks again for your thorough explanations of why it's difficult to ship robust software. And of course for OHAttributedLabel, which is a nifty tool !