Ios12commoncrypto

[radianttap]

This approach, as explained in this SO answer works rather well. It checks if CommonCrypto is available and if yes (on iOS 12) it does nothing.
On earlier version it automatically creates CommonCrypto module map.

Fixes #102

[KeimyPlaza]

Is better solution, compatibility for old version

[crisbarril]

Great work. This should work.

[b-onc]

Can we get this merged, please?

[KeimyPlaza]

@kylef Can you accept this PR? Xcode 10 GM is already released

Thanks

[quver]

@radianttap could you resolve conflicts?

[radianttap]

@quver I would gladly, but not sure how. What I should do..?

In master there is no project file. This whole fix is actually updating the project file.

[quver]

Have you tried to merge kylef:master to your branch?

[radianttap]

Just tried locally and ends up with unbuildable mess. :( Conflict resolution suggests deleting the pbxproj file. There is no solution I can pull of here.

The problem here is that kylef/jwa branch (which seems like a private dev branch) was cherry picked into master for no reason I can understand.
I think that master should be rolled back a bit – this commit seems appropriate – and the merging would be possible then.

[radianttap]

Take a look at the master branch on my fork, where I did just that - reverted to mentioned commit and merge ios12commoncrypto branch into it. It merges without conflicts.

[jeannustre]

@radianttap It breaks compatibility with Xcode 9.4.1 for me. Is it expected ?

[radianttap]

@radianttap It breaks compatibility with Xcode 9.4.1 for me. Is it expected ?

@jeannustre From last week yes. My fork/master is my personal space :) thus I already updated it to Swift 4.2. Also with podspec branch, which I'm personally using in a client project. I could not wait anymore, I needed this to work in Xcode 10, Swift 4.2.

The ios12commoncrypto branch remains intact so it could be merged here (after proposed changes to the master here).

[KeimyPlaza]

@radianttap About podspec file, Is this line correct if the CommonCrypto folder was deleted?

spec.preserve_paths = 'CommonCrypto/{shim.h,module.modulemap}'

thks a lot

[radianttap]

@radianttap About podspec file, Is this line correct if the CommonCrypto folder was deleted?

spec.preserve_paths = 'CommonCrypto/{shim.h,module.modulemap}'

Probably not. I did not see any error, thus pod seems to ignore useless instructions.

[judithgomlor]

@radianttap It breaks compatibility with Xcode 9.4.1 for me. Is it expected ?

@jeannustre From last week yes. My fork/master is my personal space :) thus I already updated it to Swift 4.2. Also with podspec branch, which I'm personally using in a client project. I could not wait anymore, I needed this to work in Xcode 10, Swift 4.2.

Exists compatibility with Xcode 9.4.1 and Xcode 10.0 if we add next line in podspec:

spec.script_phase = { :name => 'CommonCrypto', 
                        :script => 'COMMON_CRYPTO_DIR="${SDKROOT}/usr/include/CommonCrypto"
                        if [ -f "${COMMON_CRYPTO_DIR}/module.modulemap" ]
                        then
                          echo "CommonCrypto already exists, skipping"
                        else
                          FRAMEWORK_DIR="${BUILT_PRODUCTS_DIR}/CommonCrypto.framework"

                          if [ -d "${FRAMEWORK_DIR}" ]; then
                            echo "${FRAMEWORK_DIR} already exists, so skipping the rest of the script."
                            exit 0
                          fi

                          mkdir -p "${FRAMEWORK_DIR}/Modules"
                          echo "module CommonCrypto [system] {
                            header \\"${SDKROOT}/usr/include/CommonCrypto/CommonCrypto.h\\"
                            export *
                          }" >> "${FRAMEWORK_DIR}/Modules/module.modulemap"

                          ln -sf "${SDKROOT}/usr/include/CommonCrypto" "${FRAMEWORK_DIR}/Headers"
                        fi', 
                        :execution_position => :before_compile }

[juanvcarbonell]

Please guys, merge this...

[alexandrekarst]

Hi, we are providing a third-party library which contains a dependency to JSONWebToken. Could we help in any way to make this fix merged?

[carlosalban]

Anything we can do to move this along?

[dylanreich]

Just another bump :)