Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Update podspec to let user choose if logs are ON or OFF #545

Closed
AliSoftware opened this Issue · 19 comments

6 participants

@AliSoftware

Each time I do a pod update on my project, Cocoapods retrieve the MagicalRecord pod without its #define MR_ENABLE_ACTIVE_RECORD_LOGGING 0 set in its Pods-{TargetName}-MagicalRecord-prefix.pch files so I have to edit all those .pch files to disable the logs after each pod update.

Would it be possible to use supspecs so that the user can select if he wants to retreive MagicalRecord with logs ON or OFF by default?


Something maybe like this in the MagicalRecord.podspec should do the trick (not tested):

s.prefix_header_contents = <<-EOS
#ifdef __OBJC__
#define MR_SHORTHAND
#import "MagicalRecordConfig.h" // Import the config depending on the subspec
#import "CoreData+MagicalRecord.h"
#endif
EOS

s.default_subspec 'logsOn'
s.subspec 'logsOn' do |sp|
  s.source_files 'Configs/LogsOn/MagicalRecordConfig.h' // Use this MagicalRecordConfig.h file to turn logs ON
end
s.subspec 'logsOff' do |sp|
  s.source_files 'Configs/LogsOff/MagicalRecordConfig.h' // Use this MagicalRecordConfig.h file to turn logs OFF
end

And of course adding to the source repo a Config/LogsOn/MagicalRecordConfig.h file with #define MR_ENABLE_ACTIVE_RECORD_LOGGING 1 in it and a Config/LogsOff/MagicalRecordConfig.h file with #define MR_ENABLE_ACTIVE_RECORD_LOGGING 0 in it.


This way, users can either specify pod 'MagicalRecord/logsOn' or pod 'MagicalRecord/logsOff' in their Podfile. (pod 'MagicalRecord' will defaults to same as pod 'MagicalRecord/logsOn').

@casademora
Owner
@AliSoftware

@casademora That won't work, I tried.

Actually you can't just use prefix_header_contents in a subspec, because this parameter is a "Top Level Attribute" (according to the CocoaPods doc).

I did tried it anyway, like this:

s.default_subspec 'logsOn'
s.subspec 'logsOn' do |sp|
  sp.prefix_header_contents = <<-EOS
...
#define MR_ENABLE_ACTIVE_RECORD_LOGGING 1
...
EOS
end
s.subspec 'logsOff' do |sp|
  sp.prefix_header_contents = <<-EOS
...
#define MR_ENABLE_ACTIVE_RECORD_LOGGING 0
...
EOS
end

But all it does is adding all the prefix_header_contents one after the other, regardless of which subspec is selected, so you will have your lines duplicated in the PCH, one with LOGGING set to 0, one with 1 (And that's coherent with what the doc says), whatever supspec you ask in your Podfile.

And moreover, pod spec lint will complain that you have subspecs that are empty and don't have any source_files set.

This is why I suggested my approach above, this does not come out of the blue ;)


The root problem is that when you have, say, 6 targets in your project, you will have to change the value of the #define in 6 different places (in 6 different .pch files), and you will have to do it each time you execute pod update (which is quite often for my case as we also use CocoaPods with internal libraries — like many others do too — and our libraries evolve quite quickly).

Whereas if you provide the two variants in your podspec, people can choose between having the logs ON or OFF by default, without having to change it in multiple different PCH files each time they want to change it and each time they pod update their project.

@AliSoftware

Up with this, since there is now a subspec for "Shorthand" that adds MR_SHORTHAND to the pch, maybe extend the same idea as MR_SHORTHAND with Logs and NoLogs?

  s.subspec "NoLogs" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = '#define MR_ENABLE_ACTIVE_RECORD_LOGGING 0', '#import <CoreData/CoreData.h>', '#import "CoreData+MagicalRecord.h"'
  end

  s.subspec "Shorthand" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = '#define MR_SHORTHAND 0', '#import <CoreData/CoreData.h>', '#import "CoreData+MagicalRecord.h"'
  end

  s.subspec "ShorthandNoLogs" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = '#define MR_ENABLE_ACTIVE_RECORD_LOGGING 0', #define MR_SHORTHAND 0', '#import <CoreData/CoreData.h>', '#import "CoreData+MagicalRecord.h"'
  end
@AliSoftware

More readable version:

  defNoLogs = '#define MR_ENABLE_ACTIVE_RECORD_LOGGING 0'
  defShorthand = '#define MR_SHORTHAND 0'
  imports = [ '#import <CoreData/CoreData.h>', '#import "CoreData+MagicalRecord.h"' ]

  s.subspec "Core" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = *imports
  end

  s.subspec "NoLogs" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = defNoLogs, *imports
  end

  s.subspec "Shorthand" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = defShorthand, *imports
  end

  s.subspec "ShorthandNoLogs" do |sp|
    sp.source_files = 'MagicalRecord/**/*.{h,m}'
    sp.prefix_header_contents = defNoLogs, defShorthand, *imports
  end
@tonyarnold
Owner

This should be fixed in develop — I've back ported @casademora's work from MagicalRecord 3. You can now use the + [MagicalRecord setLogLevel:…] method to set the desired logging level while your application is running.

@tonyarnold tonyarnold closed this
@AliSoftware

yay! :+1:

@ealeksandrov

@tonyarnold is this really fixed? What about MR_LOGGING_ENABLED from MagicalRecordLogging.h/L34?
When I am using just [MagicalRecord setLogLevel:MagicalRecordLogLevelVerbose]; the logs are empty. But if add #define MR_LOGGING_ENABLED 1 in pod's prefix - it's working normally.

@tonyarnold
Owner

Yeah, I need to remove the reliance on MR_LOGGING_ENABLED — thanks for pointing that out!

Update: This probably needs thought — there's an imperceptible performance impact to leaving logging enabled (even if you've specified MagicalRecordLogLevelOff). I'm open to suggestions.

@tonyarnold
Owner

Righto — 8f8c28a for MagicalRecord 2.3.0, and ffb7985 for MagicalRecord 3.0. I'll be interested to hear any feedback about performance impacts this has — it shouldn't be noticeable at all.

@tonyarnold tonyarnold self-assigned this
@ealeksandrov

That was quick, thanks :+1:
But in 3.0 there is another occurrence of MR_LOGGING_ENABLED in NSManagedObjectContext+MagicalSaves.m/L65.
Maybe it should be updated, like the one in develop?

And I don't think this can lead to any serious performance issues.

@tonyarnold
Owner

:boom: 0763bb4 :boom:

Yeah, I wouldn't think the performance impacts would even be noticeable without using Instruments and a whole lot of pedantry :thumbsup:

@ealeksandrov

Awesome! :+1:
MR3.0 finally working flawlessly from CocoaPods without any hacks :smiley: Thanks for your work!

@tonyarnold
Owner

You're welcome! I'm a CocoaPods user as well, so this had bugged me for a while :grinning:

@sokol8

Hi guys,

I'm a bit confused. The latest version of Magical record available through the pods is 2.2 (dated June 2013) which doesn't contain

[MagicalRecord setLogLevel:MagicalRecordLogLevelVerbose];

How can I get access to MagicalRecord setLogLevel: functionality?

@Alydyn

You'll want to have CocoaPods get the develop branch:
#932 (comment)

@AliSoftware

@sokol8 this feature is only a available in MagicalRecord 3.0 which, AFAIK, is still in RC. While 3.0 — which is a major rewrite — continues to be tested and developed until it's official release, 2.x remains the latest stable version ATM. [EDIT] Well as tony said above, it was finally back-ported to 2.3

You may either wait for 3.0 (or 2.3) to be officially out of Beta/RC (the official MR maintainers like @tonyarnold might tell you if they plan to release it soon or if they have other priorities) or you can test it right away without waiting — simply use the dedicated branch/tag of the GIT repo, by specifying it in your Podfile to enforce using it.

@Alydyn

@AliSoftware I just checked the headers for MR v2.3beta5 and it includes the method he references:
https://github.com/magicalpanda/MagicalRecord/blob/v2.3.0-beta.5/MagicalRecord/Core/MagicalRecord%2BOptions.h#L146

I believe he can get that version with CocoaPods by following the link in my previous comment.

@Alydyn

@AliSoftware also I disagree about 2.2 being the latest stable version. v2.3 is really what you want to be on (the develop branch)

@AliSoftware

@AliSoftware I just checked the headers for MR v2.3beta5 and it includes the method he references:

Good catch. I thought it was only introduced in 3.0 and was on my iPhone when answered so didn't take the time to check the source code. Thanks!

@AliSoftware also I disagree about 2.2 being the latest stable version. v2.3 is really what you want to be on (the develop branch)

Same as above, didn't check as I was posting from my iPhone, thanks for correcting me. I edited my comment to change it to 2.x which was what I actually meant.

Bottom line is: this method is not included in the last official released pod, but is available in other branches and anyone can point to those branches if they don't want to wait for the official release of these methods.

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.