I want to build AJTCL Base Services and run the tcl base services samples (notification, controllee etc).
I can build the AJTCL core successfully.
But when I build the base_tcl with the given instructions at the https://allseenalliance.org/framework/documentation/develop/building/thin-linux page it fails.
I both tried 15.09 and master
scons WS=off AJ_TCL_ROOT=../../core/ajtcl/
scons: Reading SConscript files ...
Checking for uncrustify command...(cached) no
Checking for AllJoyn library ajtcl...no
Checking for C function AJ_EnableSoftAP()... (cached) no
Missing required external libraries
Take a look at our Jenkins, in particular the console output of this job, to see exactly how we build the SDKs.
I can manage to build the master branches of the both AJTCL and BASE_TCL as of March 11.
Just be sure to build the AJTCL first and then build the BASE_TCL by using the AJTCL outputs.
You can also check it at the base_tcl's SConstruct file, there is AJTCL_DIST variable which should point to the AJCTL's dist folder.
Related
Is it possible to create a build tool plugin that runs after the build and copies build artifacts to another location in the package directory?
For example, say I have an executable target named tool. Each time that I build tool, I'd like to copy the build artifact from .build/release/tool to ./tool so that it's available at the root of the package.
As far as I can tell, this can't be done. But I may be missing something.
(Crosspost: https://forums.swift.org/t/swift-package-plugin-copy-build-artifact/60765)
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
I have cross compiled gRPC (v1.27.3) for QNX 7 (ARM) platform. I am using the protobuf which was already available for our system (QNX ARM v3.11.4).
I used following cmake command to build gRPC for compilation process
cmake -DCMAKE_CROSSCOMPILING=1 -DgRPC_BUILD_TESTS=OFF -DgRPC_PROTOBUF_PROVIDER=package -DgRPC_SSL_PROVIDER=package -DgRPC_ZLIB_PROVIDER=package -DOPENSSL_CRYPTO_LIBRARY=$QNX_TARGET/aarch64le/usr/lib/libcrypto.a -DOPENSSL_SSL_LIBRARY=$TARGET/aarch64le/usr/lib/libssl.a -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=/tmp/qnxarm/toolchain.cmake -DCMAKE_INSTALL_PREFIX=/tmp/qnxarm/inst ../..
make plugins
make -j4
sudo make install
After compiling, I am able to see the binaries in /tmp/qnxarm/inst folder.
I copied those binaries in our code to compile the application for QNX.
While compiling I am getting this issue:
<local_directory>/grpc/aarch64/qnx/bin/grpc_cpp_plugin: program not found or is not executable
Please specify a program using absolute path or make sure the program is available in your PATH system variable
--grpc_out: protoc-gen-grpc: Plugin failed with status code 1.
lib/qmonitor/proto/CMakeFiles/QMonitorProto.dir/build.make:105: recipe for target 'lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc' failed
make[2]: *** [lib/qmonitor/proto/QAicMonitorInternal.grpc.pb.cc] Error 1
Please help me to know what is wrong? or what should be done to solve this.
Do we need to add the PATH in gRPCTargets.cmake file which is generated in lib folder?
You've compiled the gRPC tools for your QNX ARM system -- so the version of grpc_cpp_plugin you made is expecting to be run on your QNX system, not your build host.
The usual approach for this sort of thing is to make a second copy of gRPC compiled for your build host, and then instruct your application build to link the libraries from the cross build, but call the grpc_cpp_plugin compiled for the build host.
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.
So I know you can use ant and mvn to test the project, but I was wondering if there was a way to deploy the project directly as a executable jar or otherwise compile it into a format that can be directly ran? Thanks!
if you are serious about making a launchable desktop program (and especially if its going to be a game), you should use launch4j to make an exe file that launches the jar. It isn't hard to use, and it makes the program much more end user friendly
If your project was generated from the 1.7.2 PlayN archetype or newer, that functionality is already built in. Simply invoke:
mvn package
and a dependencies-included jar file will be generated in:
yourgame/java/target/yourgame-java-1.0-SNAPSHOT-jar-with-dependencies.jar
you can test it by running it standalone like so:
java -jar yourgame/java/target/yourgame-java-1.0-SNAPSHOT-jar-with-dependencies.jar
If your game was generated via an older PlayN archetype, the you can add the necessary bits to your java/pom.xml file by pasting in this in (merging with any existing <build> <plugins> blob):
maven-assembly-plugin
2.4
jar-with-dependencies
${mainClass}
make-assembly
package
single
Then just run mvn package as above to generate the file. Note that you will need to be building against PlayN 1.7.2 or newer as that version is the first one that supported automatic unpacking of the LWJGL native libraries needed to run on the desktop.