I have installed Yocto, and successfully ran host-prepare.sh script. I want to know that, to develop makefile based applications, what to do next, should install toolchain or ADT or kernel & filesystem images? Is there any documentation which has step by step process?
In many cases, one do not need to install Yocto at all, what is needed is just appropriate toolchain along with filesystem image to develop and test simple program with qemu (runqemu - which is emulator - a part of toolchain). These toolchains and filesystem images are available to download and ready to use. Refer 'Using Pre-Built Binaries and QEMU' section in this documentation.
Related
(Using C++) How would software developers make a profitable program to distribute? Would they used pre-compiled binaries within the project directory or something? Just learning wxWidgets and I want to make an application to put on a website.
#pizzadog,
The answer depends on the target platform.
If you are on Windows, you create a binary and use a special software to create a distribution.
If you are on *nix - the answer depends whether you want to allow the end-user to compile the software. If you do - you put the link to the source on the site and create a documentation on how to build it. If you don't - you create a special rules file depending on the *nix distribution you are targeting.
If you are on Mac - you put the application bundle for download and clearly state what is the minimal OSX version the program will run.
HTH.
Background
I have an Android app which uses native ARM64 executables (essentially GCC toolchain, extracted to app directory (/data/data/%package%/somePath) on the first run) to do some work. Due to Android 10 changes files in /data/data/.. can't have executable permission anymore.
Confirmed workaround
The workaround is to make executables look like shared libraries (libsomething.so) that are extracted by Android to /data/app/%package% dir with android:extractNativeLibs="true" in AndroidManifest.xml and are allowed to have executable permission. Symlinking might be useful to mimic the previous files structure.
The problem
The problem is that all the executables (aka new "shared libs") are packed into android apk with zip compression ratio (as apk is essentially just a zip file) which could be better if it's archived with 7zip for instance and together weight more than 100Mb which is app limitation on Android (for apk files).
The question and the proposal
How can i split the executables into a small part (that goes into /data/app/%package% and a large part (or just existing executable in /data/data/%package%)? The idea is that small executable just "loads and runs" a regular one. The benefit it that regular executable is compressed with 7zip and it makes apk size much smaller due to 7zip used with a better compression ratio.
I've been looking into direction of using of UPX but having no experience with it (note i will have to prepare executable on Mac machine (or Linux with VM or Docker) to run on Android ARM64). Also i've been thinking about creating of 7z sfx but it seems to be tricky (again, it have to be created on x86_64 and run on ARM64). Also I've found some similar QA (which recommends memexec() or fexecve()), but I'm not sure what's the optimal way to go.
Ideally I'd love to have some tiny "universal" ARM64 executable (or be able to compile it from the source code with Android NDK) that just accepts cmd and a regular executable path.
PS. App bundle and dynamic delivery modules as high-level alternatives are undesired for different reasons.
PPS. UPX did not work out of box for Android 10 (seems to be security issue).
i have a separate build-flow that can produce .out files for the MT3620/M4 core using the same gcc-arm compiler.... for reasons beyond the scope of this question, it's not practical for me to migrate this build-flow into cmake....
once i generate the .out file, my thinking was to simply envelop it within a project structure identical to the samples -- with an conforming app_manifest.json file.... from here, i could effectively run just the final step of the cmake build -- which generates the image package....
before i go down this path, is there anything obvious i'm missing here????
As of today you will need to decide to install Azure Sphere SDK Preview for Visual Studio or Azure Sphere SDK Preview for Windows (You cannot install both SDKs on the same PC.)
To develop applications, however, you need to set up your development environment and possibly install additional tools. The Azure Sphere SDK for Windows supports development with the CLI only. If you've installed this version of the SDK, you'll need to install CMake and Ninja on your PC.
If you plan to develop real-time capable applications (RTApps), you might need to install a compiler for the embedded processor and set up hardware to display output from the app.
Both Quickstarts "Build an RTapp on cmd" and "Build an RTApp with Visual Studio" require that you use CMake at some stage and those are the supported methods.
Update: New documentation improvements will be done soon to address the option of using a different build system to cmake and "yes" it should work as you suggest.
I want to use KDL (Kinematics and Dynamics Library) in robot control box. But robot control box uses SCons as their build system while KDL uses CMake.
It turned out that the control box doesn't have CMake installed. Should I install CMake in the control box? Or write SCons file for compiling KDL?
====================================================
My question is ambiguous. Sorry for that. And unfortunately, I cannot show the link of Control Box, it's not public. Here is link of KDL installation manual.
http://www.orocos.org/kdl/installation-manual
Let me make it more clear.
Forget all of previous question above and all about Control box, KDL. Let's say that you want to use one library. But the library can be built using CMake according to installation manual. Your PC doesn't have CMake installed but it has SCons, and unfortunately you should not install CMake on your PC.
If you can only use SCons, what can you do?
I know this situation is not usual, I want to know your opinion.
To answer your initial question: Yes, you should always try to install CMake, if that is a build requirement for you library and if you need to build that library from the sources.
To answer your later question: Replacing or rewriting the build system scripts is a major effort and not advisable. In general there is no script to convert build-systems. Such script might help to make the manual transformation. If you have a look at LLVM's effort to replace Autotools by CMake or Boost replacing it's own build system by CMake, you find out it takes several people several years and still not everybody is satisfied.
Often you don't need to build the library yourself. Either there are already built packages from the project directly of from your distribution (Debian etc. packages) or third party packagers like Mac Ports or NuGet.
In your case KDL provides Debian/Ubuntu packages.
Additional KDL is part of ROS, which is experimental in Homebrew for OS X.
I have a layered cmake project with a hierarchy of libraries and applications. Each of these libraries and applications has a CMakeLists.txt and a top level CMakeLists.txt that includes the sub-cmake files.
Right now we are developing and testing entirely on an x86 Linux platform but at some point we will want to start pulling the code into a Yocto build and target arm. We want to maintain being able to build for both x86 and arm.
I've seen some Yocto guides on building for x86 but these appear to build the entire world (the toolchain, linux kernel, all libraries etc) and run the image via qemu. For our desktop use this is quite a bit of overkill when our machines have compilers and we can just run the applications directly, but it would be very helpful to have bitbake build some libraries that we have dependencies on and that need to be installed to a 'virtual root'.
How can I use use bitbake for native x86 projects (in place of or in addition to cmake) and be able to leverage the recipe files for Yocto later on?
I don't have much experience with Yocto, but I'm using another embedded Linux distribution with similar concept: Buildroot. Buildroot creates toolchainfile (output/host/usr/share/buildroot/toolchainfile.cmake) for the currently selected toolchain.
You create two output folders for your project:
build-x86
build-arm
I the first folder you just execute:
cmake ../path-to-your-source
In the second one:
cmake ../path-to-your-source -DCMAKE_TOOLCHAIN_FILE=../path-to-buildroot/output/host/usr/share/buildroot/toolchainfile.cmake
If Yocto provides a toolchainfile, you can use it directly. If not you can create it yourself. See this wiki.
Update:
This section explains, how you can add your software to Buildroot (package). Here the source folder override mechanism is described.