kaa sample apps miss build files for c sdk - kaa

I have been researching kaa platform for weeks. And yesterday, I started running a sample application named gpiocontrol on kaa github. The java (android) sdk works fine. However, when trying to build the c sdk for esp8266, I find out some files are missing, which are
build.sh (Refered in readme file)
CMakelists.txt (Prompted when I tried to run cmake)
Also, I find these missing files in some previous commits of the project. So please check and re-add these files. Thank you very much kaa team.
Update
I do notice that the build files I mentioned above can be found in the /common path of the root directory (sample-apps).
Update 2
Unfortunately, the common build files does not have specific build files for esp8266 platform. Now I'm wondering which method should be used to build kaa for this platform, follow kaa documentation for esp8266 or just add the option -DKAA_PLATFORM=esp8266 to cmake command in common build.sh file? Actually, I have tried the second way but it failed :(
The common build.sh file cmake command
build() {
mkdir -p "$PROJECT_HOME/build"
cd "$PROJECT_HOME/build"
cmake -DBUILD_TESTING=OFF ..
make
}
Still wait for your response and thank you again!

The sample applications' sources you have discovered in the sample-apps repository on GitHub are first assembled by Maven build tool and then deployed into Kaa Sandbox image.
This does most of the effort necessary to build the application(s) easily using Kaa Sandbox.
Thus, the most simple way to build and run Kaa sample applications is by downloading them from Kaa Sandbox through the web interface and then building according to the guide. The guide itself is available on the Kaa Sandbox web interface and is tested for each the application delivered with the Kaa Sandbox.
More information on using Kaa Sandbox is available in the official Kaa Getting started documentation.
Please let me know if using Kaa Sandbox is not an option for you and you still need to build the applications manually.
Update: I confirm the ESP8622 platform was disabled for the Kaa Sandbox 0.10.0 release due to some issues on that platform at the release time.
We are planning to release Kaa 0.10.1 with fixes that should include ESP8622 platform fixes soon.
Update 2: You can now use master branch of the kaaproject/sample-apps repository to build GPIO Control application for ESP8266 platform according to the below without need to wait for the next release:
Create a CMakeLists.txt file within the root directory of the application with the next content:
cmake_minimum_required(VERSION 3.0.2)
include(config.cmake)
if (NOT DEFINED KAA_MAX_LOG_LEVEL)
set(KAA_MAX_LOG_LEVEL 3)
endif (NOT DEFINED KAA_MAX_LOG_LEVEL)
set(BUILD_TESTING OFF CACHE BOOL "")
if (NOT DEFINED KAA_SDK_PATH)
add_subdirectory(libs/kaa)
else (NOT DEFINED KAA_SDK_PATH)
add_subdirectory(${KAA_SDK_PATH})
endif (NOT DEFINED KAA_SDK_PATH)
install(TARGETS demo_client DESTINATION bin)
Extract the Kaa SDK into libs/kaa directory.
Then run (formatted as single command):
mkdir build && \
cd build && \
cmake .. \
-DCMAKE_TOOLCHAIN_FILE=../libs/kaa/toolchains/esp8266.cmake \
-DKAA_PLATFORM=esp8266 && \
make

Related

Where do I find JavaFX ant tasks in Java 11?

VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist

How to tell Visual Studio Code compiled from source where to find sqlite module?

I am building the Visual Studio Code from the source checked out from the git repository:
git clone https://github.com/microsoft/vscode
I am building using:
export NODE_OPTIONS=--max_old_space_size=2048
./scripts/npm.sh install --arch=armhf
./scripts/code.sh
I am using node 10.16.3 on a Raspberry PI 4, using Raspbian buster
There were no errors during build.
The installation downloads a precompiled version of electron on the first run.
However each time I try and run code, it starts but with an error:
[storage state.vscdb] open(): Unable to open DB due to Error: Cannot find module '../build/Release/sqlite
If I look in node_modules/vscode-sqlite3/build/Release/
I can see:
sqlite3.a
sqlite.a
It is unclear to me why electron/vscode cannot find this library. I would be greatful for any pointers on how to tell the runtime where to look for the modules.
On inspecting the build scripts and after many painful experiments, I've found and solved the 2 problems leading to this error.
The fact that .a static libraries are left behind hinted that some settings in the binding.gyp, config.gpy and/or makefiles are wrong, as Native Node Modules are normally dynamic libraries with an .node extension. One conditional line in the binding.gyp file under vscode-sqlite3 seems to the the culprit:
...
["target_arch=='arm'", {"type": "static_library"}]
...
Disable that line (by removing it or changing 'arm' to something else) and then run:
node-gyp configure
to regenerate the config.gpy file(s) under the build directory. Then build the module with:
node-gyp build
A sqlite.node will be generated in build/Release.
Unfortunately, the latest electron ABI version rarely matches that of the Node.js version. In my configuration, the electron ABI version is 72 (v6.0.12) but the latest stable Node version is for ABI 64. Therefore we have to do an electron-rebuild to update the sqlite.node to match the electron version.
To do this, you would have to first install electron-rebuild (yarn add electron-rebuild) then run electron-rebuild by giving supplying explicitly the version number of the electron binary that vscode downloaded:
electron-rebuild -v 6.0.12 -m /home/dev/vscode -o vscode-sqlite3
Of course you would have to state the version number of your particular version of electron you are building for.
(Please look up electron-rebuild --help for the meaning of the options. It takes a while to rebuild the binary module...)
The resulting sqlite.node can then be moved into the build/Release/. directory under the vscode project directory. Voila, we have a working latest version VS-Code for Raspbian!

How to deploy a sample GRPC [client-server] solution in raspberri pi in dotnet core

I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.

how to solve "Failed at the fibers#2.0.0 install script' error while deploying the meteor app?

I know how to package and then deploy meteor application. But recently for one project i'm stuck at an error which i couldn't resolve.
Steps I followed for package and deploy of my meteor app:
1. meteor build package
2. cd package
3. tar -xf inventoryTool.tar.gz
4. cd bundle/programs/server
5. npm install
6. cd ../..
7. PORT=<port> MONGO_URL=mongodb://127.0.0.1:27017/dbName ROOT_URL=http://<ip> node main.js
Here is the log for the error when i run the npm install(STEP 5) command.
Is there anything missing in my execution?. I'm not using the fibers package anywhere in my project. Does anyone have solution to this problem? Thanks in advance.
Why this happens (a lot)?
Your local version of node is v8.9.4. When using the build command, you will export your application and build the code against this exact node version. Your server environment will require this exact version, too.
An excerpt from the custom deployment section of the guide:
Depending on the version of Meteor you are using, you should install
the proper version of node using the appropriate installation process
for your platform. To find out which version of node you should use,
run meteor node -v in the development environment, or check the
.node_version.txt file within the bundle generated by meteor build.
Even if you don't use fibers explicitly it will be required to run your Meteor app on the server correctly.
So what to do?
In order to solve this, you need to
a) ensure that your local version of node exactly matches the version on the server
b) ensure that you build against the server's architecture (see build command)
To install a) the very specific node version on your server you have two options:
Option I. Use n, as described here. However this works only if your server environment uses node and not nodejs (which depends on how you installed nodejs on the server).
II. To install a specific nodejs version from the repositories, you may do the following:
$ cd /tmp
$ wget https://deb.nodesource.com/node_8.x/pool/main/n/nodejs/nodejs_8.9.4-1nodesource1_amd64.deb
$ apt install nodejs_8.9.4-1nodesource1_amd64.deb
If you are not sure, which of both are installed on your server, check node -v and nodejs -v. One of both will return a version. If your npm install still fails, check the error output and if it involves either node or nodejs and install the desired distribution using the options above.
To build b) against the architecture on your server, you should use the --architecture flag in your build command.

Deploy SNAPSHOT artifact and sources to Nexus from Maven command line

I am trying to deploy one EXE file and it's zipped source file to Sonatype Nexus using maven command line. Files must be deployed as SNAPSHOTs.
So, I have 2 files:
-testXYZ.exe and source file
-testXYZ.zip
Using maven 2.2.1 and command described here:
mvn deploy:deploy-file -Durl=file:///home/me/m2-repo \
-DrepositoryId=some.repo.id \
-Dfile=./path/to/artifact-name-1.0.jar \
-DpomFile=./path/to/pom.xml \
-Dsources=./path/to/artifact-name-1.0-sources.jar \
-Djavadoc=./path/to/artifact-name-1.0-javadoc.jar
I can deploy EXE, but cannot deploy source, because maven 2.2.1 is using deploy-plugin v2.5 and this command is not supported until v2.7.
It is not allowed to me to use newer versions of maven, so I try different approach.
Using these two subsequent commands I can deploy these two artifacts, but, source cannot be downloaded from nexus.
call mvn deploy:deploy-file -DgroupId=com.xyz -DartifactId=testXYZ -Dversion=1.1.116-SNAPSHOT -Dpackaging=zip -Dfile=testXYZ.zip -Dclassifier=sources -Durl=http://build:8081/nexus/content/repositories/snapshots -DrepositoryId=nexus
call mvn deploy:deploy-file -DgroupId=com.xyz -DartifactId=testXYZ -Dversion=1.1.116-SNAPSHOT -Dpackaging=exe -Dfile=testXYZ.exe -Durl=http://build:8081/nexus/content/repositories/snapshots -DrepositoryId=nexus
After deploy, i search for testXYZ and click on artifact source download link.
Nexus says:
"Item not found on path
"com.xyz:testXYZ:1.1.116-SNAPSHOT:c=sources:e=jar"!"
Problem is the way maven upload these artifacts:
Line form log file while source is uploading:
Uploaded: http://build:8081/nexus/content/repositories/snapshots/com/xyz/testXYZ/1.1.116-SNAPSHOT/testXYZ-1.1.116-20120106.111705-1-sources.zip
Line form log file while Main artifact is uploading:
Uploaded: http://build:8081/nexus/content/repositories/snapshots/com/xyz/testXYZ/1.1.116-SNAPSHOT/testXYZ-1.1.116-20120106.111709-2.exe
Notice 111705-1 and 111705-2. Last number must be the same if we wish Nexus can generate correct links.
This approach is described here:
Deploying an artifact, its sources and javadoc using maven's deploy:deploy-file plugin
and here:
http://maven.apache.org/plugins/maven-install-plugin/examples/installing-secondary-artifacts.html
and it working for fixed versions(for example 1.1.116), but not for SNAPSHOTs.
Exe and Zip files can be deployed to Nexus (like jar files), if fixed version is used.
So, question is:
Is there a way to deploy artifact and source SNAPSHOTs from command line to Sonatype Nexus and to be sure that these files can be downloaded by clicking on sources and artifacts links?
Note:
If I disable timestamps suffix, this can work, but I do not want to do this.
-DuniqueVersion=false
Thanks,
Marjan
I found partial solution for this problem. I can call specific version of maven-deploy-plugin like this:
mvn org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file...
This way, artifacts and sources SNAPSHOTs can be deployed to Nexus avoiding any problems with download, but it behave like
-DuniqueVersion=false
is still there.

Resources