@axxel before this Pod gets published we could also rename the file to ZXingCpp.podspec which is probably more sound with the Swift / iOS naming but in the end more a personal preference.

Do you want the Pod to be published as zxing-cpp or ZXingCpp on CocoaPods? Both is possible, your call! :)

which is basically an alias due to the declared dependency for

Interesting, I don't see any dependency of the root entity on the Wrapper. Is pod zxing-cpp simply pulling all subspecs?

Do you want the Pod to be published as zxing-cpp or ZXingCpp on CocoaPods?

In my comment I argued that there would be some consistency if we used the term zxing-cpp (see the PyPi situation). I also thought that from an iOS developers perspective who might use SPM (via the github url) and/or CocoaPods (via the pod command), it makes sense that both access paths use the same term (zxing-cpp). On the other hand, if the CocoaPods namespace obviously settled for PascalCase and the s.module_name is ZXingCpp then maybe that internal consistency trumps the other?

Lets vote? (@benjohnde @ryantrem @alexmanzer @parallaxe):
👍 = zxing-cpp
👎 = ZXingCpp

@axxel good catch! s.default_subspec = 'Wrapper' was missing, my bad! Now my initial post is valid. That's the way CocoaPods recommends to do it: https://guides.cocoapods.org/syntax/podspec.html#default_subspecs

A Pod should make available the full library by default. Users can fine tune their dependencies, and exclude unneeded subspecs, once their requirements are known.

CocoaPods uses the name of the spec which should be the same as the filename as module name. That's why I added the module name as it is different.

The main obstacle to talk about is how the module should be named on CocoaPods, I don't really have an opinion. A weak statement would be that zxing-cpp is probably the better choice as the name of this project and repo is the same.

Lets vote? (@benjohnde @ryantrem @alexmanzer @parallaxe): 👍 = zxing-cpp 👎 = ZXingCpp

Personally I really like zxing-cpp because it's more consistent to this whole repo/project.
But in the iOS world, there is unfortunately another convention regarding the naming of frameworks/libs, so for iOS I would stick with ZXingCpp, as you can see here:

Hey @alexmanzer, as it is committed as of now, the Pod name would be zxing-cpp but the module is named ZXingCpp.

So you would require the Pod zxing-cpp but import ZXingCpp as module. Not quite sure whether this makes a difference in your decision but just to paint the picture in a complete way.

With 3 votes for zxing-cpp as the CocoaPods name that seems settled. I understand that this is ready for merging, right?

@benjohnde maybe you can give one final look at the multitude of places where a name shows up and make sure they are not somehow contradicting each other: zxing-cpp.podspec: s.name, s.module_name, Package.swift: Package-, Library-, Taget-name, demo.xcodeproj/*

Awesome!

@axxel I will look into that after the weekend to the latest and also provide a meaningful README section, which is subject to be reviewed by @alexmanzer :)

Do you want to have this placed in the root README or should I use the wrappers/ios/README?

@axxel I can point to a subfolder for the Pod readme btw https://guides.cocoapods.org/syntax/podspec.html#readme depends on your flavour!

Do you want to have this placed in the root README or should I use the wrappers/ios/README?

The latter.

@axxel done. Next steps are:

• merge
• prepare new release (i.e. adjust version number and maybe tag of source in the zxing-cpp.podspec file)
• create new release
• Then I will push the Spec to CocoaPods
• that's it