Build flatpak package from prebuild binaries (mono and gtk-sharp2 project) - build

I'm trying to pack my application with flatpak and currently I'm stuck:
How do I make shure, that the runtimes are installed on the target system? I need mono, gtk-sharp2, SFML, CSFML. I learned about the basic runtime, but what about my dependencies?
How do I run the application? I tried
[sven#localhost flatpak]$ flatpak-builder --run build net.sourceforge.audiocuesheet.json /app/AudioCuesheetEditor/./AudioCuesheetEditor
bwrap: execvp /app/AudioCuesheetEditor/./AudioCuesheetEditor: No such file or directory
Some more information about the project:
net.sourceforge.audiocuesheet.json:
{
"app-id": "net.sourceforge.audiocuesheet",
"runtime": "org.gnome.Platform",
"runtime-version": "3.26",
"sdk": "org.gnome.Sdk",
"command": "/AudioCuesheetEditor/AudioCuesheetEditor",
"modules": [
{
"name": "AudioCuesheetEditor",
"buildsystem": "simple",
"build-commands": [
"cp -r AudioCuesheetEditor /app/AudioCuesheetEditor",
"chmod +x /app/AudioCuesheetEditor/AudioCuesheetEditor"
],
"sources": [
{
"type": "archive",
"path": "AudioCuesheetEditor-linux-x64-v2.4.2.zip",
"dest": "AudioCuesheetEditor"
}
]
}
]
}
As you can see, the archive has prebuild binaries, which I would like to deploy to the target maschines. I'm new to flatpak and not really shure, if I'm doing right, so maybe some help from you would be perfect.
Thanks
Sven

Related

Visual Studio compiling to wrong path AND trying to run wrong path when used with CMake

I'm very new to CMake (and new to C++ too, although that shouldn't matter here), and I am having a problem using CMake with Visual studio.
I have created a directory, let's say it's called Project, and put in it a simple project with the following structure:
Project/
build/ <empty>
src/
main.cpp
CMakeLists.txt
CMakePresets.json
Inside these files is just the most basic, default code:
CMakeLists.txt:
cmake_minimum_required (VERSION 3.8)
project (Project)
set (CMAKE_CXX_STANDARD 20)
set (CMAKE_CXX_STANDARD_REQUIRED True)
add_executable (Project src/main.cpp)
CMakePresets.json (this code is just the default that was generated):
{
"version": 3,
"configurePresets": [
{
"name": "windows-base",
"hidden": true,
"generator": "Ninja",
"binaryDir": "${sourceDir}/out/build/${presetName}",
"installDir": "${sourceDir}/out/install/${presetName}",
"cacheVariables": {
"CMAKE_C_COMPILER": "cl.exe",
"CMAKE_CXX_COMPILER": "cl.exe"
},
"condition": {
"type": "equals",
"lhs": "${hostSystemName}",
"rhs": "Windows"
}
},
{
"name": "x64-debug",
"displayName": "x64 Debug",
"inherits": "windows-base",
"architecture": {
"value": "x64",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
}
},
{
"name": "x64-release",
"displayName": "x64 Release",
"inherits": "x64-debug",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Release"
}
},
{
"name": "x86-debug",
"displayName": "x86 Debug",
"inherits": "windows-base",
"architecture": {
"value": "x86",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Debug"
}
},
{
"name": "x86-release",
"displayName": "x86 Release",
"inherits": "x86-debug",
"cacheVariables": {
"CMAKE_BUILD_TYPE": "Release"
}
}
]
}
src/main.cpp:
#include <iostream>
int main() {
std::cout << "Hello, world!" << std::endl;
return 0;
}
Then, I have used CMake to create a Visual Studio solution:
C:\...\Project\build> cmake ..
This has worked fine without any errors, and Visual Studio can open the solution. It can also build the project correctly...
But it cannot run the executable which it has built. After successfully building the project, it has written the executable to C:\...\Project\build\Debug\Project.exe, but it tries to open C:\...\Project\build\x64\Debug\ALL_BUILD instead, and I get an error popup.
I gather that there are two things wrong here:
The executable file should be written within the C:\...\Project\build\x64\Debug folder, not just the C:\...\Project\build\Debug folder. This is how it has worked whenever I have used Visual Studio before, and this is the folder it is trying to search in.
It should be searching for an executable called Project.exe, not one called ALL_BUILD.
When I run Project.exe manually from the command line, it works fine. But I cannot seem to make Visual Studio run it correctly.
What have I done wrong here, and how can I get this to work?
Default project is set to ALL_BUILD to change the default for the VS generators use the following CMake statement:
set_property(DIRECTORY PROPERTY VS_STARTUP_PROJECT Project)
Anywhere after the add_executable command.
You see several projects in the solution explorer. These projects are build targets. The default target is ALL_BUILD, that builds all configured targets, like cmake --build . does it.
Set required target as the startup project in the solution explorer. This will point the debugger what executable to run.

How to hit Vscode breakpoints in unit tests from within a docker-compose setup running Django

What I'm trying to do seems simple enough, but it's been crazy hard to actually get there. I have a Django application that runs in a docker-compose environment, and I want to run and debug the unit tests with breakpoints in Vscode.
Since this is a big project with a team that doesn't necessarily use vscode, I can't add libraries willy-nilly (like ptvsd, for example). I'm hoping there's a magic configuration for tasks.json and launch.json that will makes things work.
I have a container for a postgres database, one for django, and one for redis, all defined in docker-compose.yml. There's a command that I can run in the terminal that will run the tests, it's:
docker-compose run --rm app python manage.py test
where app is the django app container. I'd love to be able to run this command in such a way that it can hit breakpoints in vscode.
My incomplete stab at the launch.json file looks like this:
{
"configurations": [{
"name": "Docker: Python - Django",
"type": "docker",
"request": "launch",
"preLaunchTask": "compose-for-debug",
"python": {
"pathMappings": [{
"localRoot": "${workspaceFolder}",
"remoteRoot": "/app"
}],
"projectType": "django"
}
}]
}
And my tasks.json:
{
"version": "2.0.0",
"tasks": [{
"type": "docker-build",
"label": "docker-build",
"platform": "python",
"dockerBuild": {
"tag": "dockerdebugging:latest",
"dockerfile": "${workspaceFolder}/Dockerfile",
"context": "${workspaceFolder}",
"pull": true
}
},
{
"type": "docker-run",
"label": "docker-run: debug",
"dependsOn": [
"docker-build"
],
"python": {
"args": [
"test",
"--nothreading",
"--noreload"
],
"file": "manage.py"
}
}
]
}
I think I need to convert the build task to a docker compose task somehow, but I just can't figure out how its done. It may also make sense to run the containers in the terminal, and somehow make vscode attach to them with breakpoints enabled.
Even some help with how to approach this would be great. I know it's a tricky one.
This question became somewhat popular, but a direct answer never came. If you've landed here looking for a way to hit breakpoints inside vscode using docker, my suggestion is to use the Remote Container extension.
When the container is up, right click it and open a vscode window inside of the container itself. Then everything will just work.

Node-gyp Library not loaded: /usr/local/lib/libmtp.9.dylib

I have been attempting to make a nodejs-native-addon which uses libmtp to carry out certain functions. I have been successful in the building the app but the app is throwing Library not loaded: /usr/local/lib/libmtp.9.dylib. Referenced from: /path/build/Debug/nbind.node. Reason: image not found error when I try to run it on another macbook where the libmtp isn't installed.
This is my binding.gyp file:
{
"targets": [
{
"includes": [
"auto.gypi"
],
"sources": [
"src/native/mtp.cc"
],
"link_settings": {
"libraries": [
"-lmtp"
],
},
}
],
"includes": [
"auto-top.gypi"
],
}
I even attempted to include the dylib file in the libraries option
"link_settings": {
"libraries": [
"<(module_root_dir)/src/native/lib/libmtp.9.dylib"
]
}
but the app fails to start with the Library not loaded: /usr/local/lib/libmtp.9.dylib. Referenced from: /path/build/Debug/nbind.node. Reason: image not found error.
Any help will be appreciated.
The error is indicating that the library libmtp.9.dylib cannot be found in the standard library include path /usr/local/lib
Try setting the environment variable LD_LIBRARY_PATH to point to the location where you have the libmtp.9.dylib before running the node.
One solution would be to create a symlink in a known rpath like /usr/local/lib manually to your built library. Not ideal but it may provide a workaround for at least having successful builds in development.
ln -s <absolute_path>/src/native/lib/libmtp.9.dylib /usr/local/lib/libmtp.9.dylib
This allows the binding.gyp file to find the library without it needing to configure an rpath with whatever process is throwing the error. This is easier in my opinion than tracking down the binding.gyp trace.

Source synchronization in Visual Studio CMake project and WSL

I have a big solution where part of projects is a classic Visual C++ projects and other part is CMake type projects.
Previously I work with Windows 7 + VS 2017 + Ubuntu on virtual machine and before start building CMake project for linux, VS start rsync for synchronization source between PC and virtual machine.
For this I was create next rule in CMakeSettings.json file:
{
"name": "Linux-Debug",
"generator": "Unix Makefiles",
"remoteMachineName": "${defaultRemoteMachineName}",
"configurationType": "Debug",
"remoteCMakeListsRoot": "/var/tmp/src/Solution_dir/",
"cmakeExecutable": "/usr/bin/cmake",
"buildRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\build\\${name}",
"installRoot": "${env.USERPROFILE}\\CMakeBuilds\\${workspaceHash}\\install\\${name}",
"remoteBuildRoot": "/var/tmp/Solution_dir/build/x86_64_debug_unix",
"remoteInstallRoot": "/var/tmp/Solution_dir/install/x86_64_release_unix",
"remoteCopySources": true,
"remoteCopySourcesOutputVerbosity": "Normal",
"remoteCopySourcesConcurrentCopies": "10",
"remoteCopySourcesMethod": "rsync",
"remoteCopyBuildOutput": false,
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "linux_x64" ],
"remoteCopySourcesExclusionList": [ "Debug", "Release", ".intermediate", ".vs", "Setup" ]
}
And now I have installed Windows 10 Pro and WSL.
By default WSL have mount my local drives(like /mnt/c, /mnt/d) and in my opinion there no more sense to make a copy of source code folder.
But if I will change remoteCMakeListsRoot property to "/mnt/d/Solution_dir" VS will start rsync that will remove my .git folder and all folders from remoteCopySourcesExclusionList property.
If I will remove remoteCopySourcesExclusionList property from CMakeSettings.json rsync will remove .git folder anyway.
What is the true way to work with WSL from Visual Studio? How can I say to VS that no need to start rsync?

Compile C++ with Docker on Visual Studio Code for macOS

I start a new project of a C++ application working on a BeagleBone Black (Ubuntu 14.04 (Trusty Tahr), ARM v7), but in the future I will do to port the application to Linux or Windows.
I want to set up a development environment who can be cross platform (especially for macOS)
For now, I use:
Visual Studio Code: I like this editor, and it is crossplatform.
CMake: I'm new to it, but I want to learn.
Docker with following things: I'm also new to Docker
arm-linux-gnueabihf-g++-4.8 as compiler
Libraries: like Poco
The goal is to build my application with my Docker image, transfer the binary on my BeagleBone Black and debug on target from my macOS Visual Studio Code instance.
Also, I try to install Visual Studio Code on my Docker image, but it's a little sluggish, and my keyboard doesn't work correctly.
I'm open to change my development setup, and I don't know the best practice.
Finally I use a "workaround" with Visual Studio Code tasks
{
// See https://go.microsoft.com/fwlink/?LinkId=733558
// for the documentation about the tasks.json format
"version": "0.1.0",
"showOutput": "always",
"runner": "terminal",
"command": "bash",
"args": [
"-c"
],
"isShellCommand": true,
"tasks": [
{
"taskName": "docker-cmake-configure",
"suppressTaskName": true,
"args": [
"docker exec -it ${config:custom.docker.defaultName} cmake --no-warn-unused-cli -DCMAKE_C_COMPILER:FILEPATH=/usr/bin/arm-linux-gnueabihf-gcc-4.8 -DCMAKE_CXX_COMPILER:FILEPATH=/usr/bin/arm-linux-gnueabihf-g++-4.8 -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -H/home/developer/project -B/home/developer/project/build"
]
},
{
"taskName": "docker-cmake-build",
"suppressTaskName": true,
"isBuildCommand": true,
"args": [
"docker exec -it ${config:custom.docker.defaultName} cmake --build /home/developer/project/build --config Debug -- -j 6"
]
}
]
}
Maybe when this issue will be solved, I can use a more integrated solution: https://github.com/vector-of-bool/vscode-cmake-tools/issues/111