CoreML in Cocoapod (pod spec lint won't work) - swift

I am attempting to update my cocoapod. Since the last update, I have added a .coreml file and not when I try pod spec lint, I am getting some errors. Things I've done:
Added s.resources = "JacquardToolkit/**/*.mlmodel" to my .podspec file
There was also a few name changes with my .coreml file. Ultimately I want to include only ForceTouch.coreml, so I also need help to get rid of the references to Forcetouch.coreml and ForceTouch2.coreml.
Here is the error message I get in terminal...

try this:
add the MLModel to your spec.source_files in your podspec:
spec.source_files = 'Classes/**/*.{swift,mlmodel,mlmodelc}'
You may also need this if it fails to compile because codegen language is not set:
spec.xcconfig = {'COREML_CODEGEN_LANGUAGE' => 'Swift', 'COREML_CODEGEN_SWIFT_GLOBAL_MODULE' => 'NO'}

Related

How to add Babel support for nullishCoalescingOperator to vue project?

In my Vue-CLI project, when I tried using the ?? operator, I got this error:
Syntax Error: SyntaxError: /Users/stevebennett/odev/freelancing/v-map/src/components/Map.vue: >Support for the experimental syntax 'nullishCoalescingOperator' isn't currently enabled (30:29):
...
Add #babel/plugin-proposal-nullish-coalescing-operator (https://git.io/vb4Se) to the 'plugins' section of your Babel config to enable transformation.
I installed #babel/plugin-syntax-nullish-coalescing-operator (its name seems to have changed), added it to my babel.config.js:
module.exports = {
presets: ['#vue/app'],
plugins: ['#babel/plugin-syntax-nullish-coalescing-operator'],
};
Now the error message seems to have gone backwards, no reference to the operator name at all:
Module parse failed: Unexpected token (39:35)
You may need an appropriate loader to handle this file type.
| case 8:
| points = _context.sent;
console.log(sheetID ?? 37);
What am I doing wrong?
For me, the #babel/plugin-syntax-nullish-coalescing-operator plugin would not work, which is the one you are using.
I had to use the #babel/plugin-proposal-nullish-coalescing-operator plugin which is the one that the error message suggests you use.
Additionally, I noticed this on the page for the #babel/plugin-syntax-nullish-coalescing-operator plugin:
I can't say for sure if this will fix your problem, but it certainly fixed mine

Check for empty file and quit cakebuild

I am attempting to write a check in my Cake build script to pull in a file from BuildParameters and check if the file contents are empty -- if contents are empty, throw an exception and quit the build.
I am attempting to use FileReadText from the FileHelpers namespace but for some reason I cannot get my build to recognize the file command. I am following the syntax and documentation found here: https://cakebuild.net/api/Cake.FileHelpers/FileHelperAliases/97F5679A
Here is the code I am trying in build.cake:
var fileReadText= FileReadText(Parameters.TestParameters.TestListFP);
var fileText= fileReadText.ThrowIfNullOrEmpty(nameof(fileReadText));
The argument Parameters.TestParameters.TestListFP is set in my Parameters.cake file as such:
TestListFP = context.File("C:\Some\Path\some_file_name.txt");
Using the above code, I see this error:
error CS0103: The name 'FileReadText' does not exist in the current
context
Note that I do not have a ICakeContext in build.cake, just BuildParameters.
I tried to resolve the issue by adding using Cake.FileHelpers; at the top of my build.cake file, but then I see this error:
The type or namespace name 'FileHelpers' does not exist in the namespace 'Cake' (are you missing an assembly reference?)
The script works fine without my FileReadText code, so I know TestListFP is actually a valid file.
I think I am inherently misunderstanding how to use FileHelpers and FileReadText and I could not find any examples of usage in documentation or anywhere else. If anyone has guidance on how to use this method, or a better way to accomplish what I am trying to do, I would appreciate the help.
Have you added the #addin pre-processor directive, as mentioned here:
https://github.com/cake-contrib/Cake.FileHelpers/#cakefilehelpers
You can easily reference Cake.FileHelpers directly in your build script via a cake addin:
#addin "Cake.FileHelpers"

How do I unit test a private Cocoapods library?

I am trying to find out how to set up unit testing for my private cocoapod library.
Here is the expecting result:
I added a unit testing target 'MyPodTests' to the 'Pods' Project, then I changed target to my 'MyPodTests' scheme. Then I created test classes for my unit tests. I can now select my 'MyPodLib' scheme and press CMD+U and the testing target executes the tests. This is the behavior I am looking for.
This approach, however, has some drawbacks. If I do 'pod update' or 'pod install' on my example app, the test target is gone. if I call pod update on my Example application, the tests are gone too. I'm certain there is a correct way to do this. Also, I would like to prevent the test classes from being loaded into any consumers using the library, therefore I added an exclusion to my podspec:
s.exclude_files = 'Pod/Classes/**/Test/*'
When I select MyPodLib and press CMD+U nothing is happening, and if I select MyPodTests and press CMD+U it throws "No such module 'MyPodLib'" error.
You'll probably want to have the tests running independently of your example app. If that's the case add a test subspec in your pod spec and set its source files.
For example, say you have an Xcode project with a framework target MyFramework and a test target MyFrameworkTests. Your pod spec will look like this:
Pod::Spec.new do |s|
s.name = "MyFramework"
s.version = "1.0.0"
s.summary = "Summary of what MyFramework does"
s.homepage = "https://www.website.com"
s.license = { :type => "MIT", :file => "LICENCE.txt" }
s.author = "Ramesh Boosa"
s.platform = :ios, "11.0"
s.swift_versions = ["5.0", "5.1"]
s.source = { :git => "https://github.com/MyName/MyFramework.git", :tag => "v#{s.version}" }
s.source_files = "MyFramework/*.swift"
s.test_spec do|test|
test.source_files = "MyFrameworkTests/*.swift"
end
end
To lint your pod spec and to run your unit tests execute pod spec lint MyFramework.podspec.
If your example app is included with your pod you can add an app host to your podspec. The CocoaPods documentation has more details.

How can I get "HelloWorld - BitBake Style" working on a newer version of Yocto?

In the book "Embedded Linux Systems with the Yocto Project", Chapter 4 contains a sample called "HelloWorld - BitBake style". I encountered a bunch of problems trying to get the old example working against the "Sumo" release 2.5.
If you're like me, the first error you encountered following the book's instructions was that you copied across bitbake.conf and got:
ERROR: ParseError at /tmp/bbhello/conf/bitbake.conf:749: Could not include required file conf/abi_version.conf
And after copying over abi_version.conf as well, you kept finding more and more cross-connected files that needed to be moved, and then some relative-path errors after that... Is there a better way?
Here's a series of steps which can allow you to bitbake nano based on the book's instructions.
Unless otherwise specified, these samples and instructions are all based on the online copy of the book's code-samples. While convenient for copy-pasting, the online resource is not totally consistent with the printed copy, and contains at least one extra bug.
Initial workspace setup
This guide assumes that you're working with Yocto release 2.5 ("sumo"), installed into /tmp/poky, and that the build environment will go into /tmp/bbhello. If you don't the Poky tools+libraries already, the easiest way is to clone it with:
$ git clone -b sumo git://git.yoctoproject.org/poky.git /tmp/poky
Then you can initialize the workspace with:
$ source /tmp/poky/oe-init-build-env /tmp/bbhello/
If you start a new terminal window, you'll need to repeat the previous command which will get get your shell environment set up again, but it should not replace any of the files created inside the workspace from the first time.
Wiring up the defaults
The oe-init-build-env script should have just created these files for you:
bbhello/conf/local.conf
bbhello/conf/templateconf.cfg
bbhello/conf/bblayers.conf
Keep these, they supersede some of the book-instructions, meaning that you should not create or have the files:
bbhello/classes/base.bbclass
bbhello/conf/bitbake.conf
Similarly, do not overwrite bbhello/conf/bblayers.conf with the book's sample. Instead, edit it to add a single line pointing to your own meta-hello folder, ex:
BBLAYERS ?= " \
${TOPDIR}/meta-hello \
/tmp/poky/meta \
/tmp/poky/meta-poky \
/tmp/poky/meta-yocto-bsp \
"
Creating the layer and recipe
Go ahead and create the following files from the book-samples:
meta-hello/conf/layer.conf
meta-hello/recipes-editor/nano/nano.bb
We'll edit these files gradually as we hit errors.
Can't find recipe error
The error:
ERROR: BBFILE_PATTERN_hello not defined
It is caused by the book-website's bbhello/meta-hello/conf/layer.conf being internally inconsistent. It uses the collection-name "hello" but on the next two lines uses _test suffixes. Just change them to _hello to match:
# Set layer search pattern and priority
BBFILE_COLLECTIONS += "hello"
BBFILE_PATTERN_hello := "^${LAYERDIR}/"
BBFILE_PRIORITY_hello = "5"
Interestingly, this error is not present in the printed copy of the book.
No license error
The error:
ERROR: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb: This recipe does not have the LICENSE field set (nano)
ERROR: Failed to parse recipe: /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
Can be fixed by adding a license setting with one of the values that bitbake recognizes. In this case, add a line onto nano.bb of:
LICENSE="GPLv3"
Recipe parse error
ERROR: ExpansionError during parsing /tmp/bbhello/meta-hello/recipes-editor/nano/nano.bb
[...]
bb.data_smart.ExpansionError: Failure expanding variable PV_MAJOR, expression was ${#bb.data.getVar('PV',d,1).split('.')[0]} which triggered exception AttributeError: module 'bb.data' has no attribute 'getVar'
This is fixed by updating the special python commands being used in the recipe, because #bb.data was deprecated and is now removed. Instead, replace it with #d, ex:
PV_MAJOR = "${#d.getVar('PV',d,1).split('.')[0]}"
PV_MINOR = "${#d.getVar('PV',d,1).split('.')[1]}"
License checksum failure
ERROR: nano-2.2.6-r0 do_populate_lic: QA Issue: nano: Recipe file fetches files and does not have license file information (LIC_FILES_CHKSUM) [license-checksum]
This can be fixed by adding a directive to the recipe telling it what license-info-containing file to grab, and what checksum we expect it to have.
We can follow the way the recipe generates the SRC_URI, and modify it slightly to point at the COPYING file in the same web-directory. Add this line to nano.bb:
LIC_FILES_CHKSUM = "${SITE}/v${PV_MAJOR}.${PV_MINOR}/COPYING;md5=f27defe1e96c2e1ecd4e0c9be8967949"
The MD5 checksum in this case came from manually downloading and inspecting the matching file.
Done!
Now bitbake nano ought to work, and when it is complete you should see it built nano:
/tmp/bbhello $ find ./tmp/deploy/ -name "*nano*.rpm*"
./tmp/deploy/rpm/i586/nano-dbg-2.2.6-r0.i586.rpm
./tmp/deploy/rpm/i586/nano-dev-2.2.6-r0.i586.rpm
I have recently worked on that hands-on hello world project. As far as I am concerned, I think that the source code in the book contains some bugs. Below there is a list of suggested fixes:
Inheriting native class
In fact, when you build with bitbake that you got from poky, it builds only for the target, unless you mention in your recipe that you are building for the host machine (native). You can do the latter by adding this line at the end of your recipe:
inherit native
Adding license information
It is worth mentioning that the variable LICENSE is important to be set in any recipe, otherwise bitbake rises an error. In our case, we try to build the version 2.2.6 of the nano editor, its current license is GPLv3, hence it should be mentioned as follow:
LICENSE = "GPLv3"
Using os.system calls
As the book states, you cannot dereference metadata directly from a python function. Which means it is mandatory to access metadata through the d dictionary. Bellow, there is a suggestion for the do_unpack python function, you can use its concept to code the next tasks (do_configure, do_compile):
python do_unpack() {
workdir = d.getVar("WORKDIR", True)
dl_dir = d.getVar("DL_DIR", True)
p = d.getVar("P", True)
tarball_name = os.path.join(dl_dir, p+".tar.gz")
bb.plain("Unpacking tarball")
os.system("tar -x -C " + workdir + " -f " + tarball_name)
bb.plain("tarball unpacked successfully")
}
Launching the nano editor
After successfully building your nano editor package, you can find your nano executable in the following directory in case you are using Ubuntu (arch x86_64):
./tmp/work/x86_64-linux/nano/2.2.6-r0/src/nano
Should you have any comments or questions, Don't hesitate !

cocoapods: The resources are not copied to mainBundle

I am struggling with resources. I want to be able to put a nib in my pod. One of the classes uses this nib.
Here is the podspec:
Pod::Spec.new do |s|
s.name = "MyCBD_BSManagedDocument"
s.requires_arc = true
s.osx.platform = :osx, '10.7'
s.subspec 'MyCBD_BSManagedDocument' do |ss|
ss.source_files = 'Classes/MyCBD_BSManagedDocument/**/*.{h,m}'
end
s.subspec 'Auxiliary classes' do |ss|
ss.subspec 'MyCBDLockManager' do |sss|
sss.source_files = 'Classes/Auxiliary classes/MyCBDLockManager/**/*.{h,m}'
sss.resource_bundle = {'MyCBDLockManager' => 'Classes/Auxiliary classes/MyCBDLockManager/MyCBDLockManager.xib'}
end
ss.subspec 'MyCBDSafeguardManager' do |sss|
sss.source_files = 'Classes/Auxiliary classes/MyCBDSafeguardManager/**/*.{h,m}'
end
end
end
Very strangely, in my toy-project to test the pod, it works (I can check the nib is in the mainBundle), but in my real project, the nib is not in the mainBundle, and I have the error
-[MyCBDLockManager loadWindow]: failed to load window nib file 'MyCBDLockManager'.
Any advice on how to include resources with cocoa pods?
For some reason, one phase in the build phases was missing. I don't know why, though.
So, I had to add this phase again with pod install.
If that phase is missing you should try to run pod install again and make sure you're opening the xcworkspace that is generated. Also you want just resources not resource_bundles for a single xib like that.