Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QNX Support #1914

Open
JaiXJM-BB opened this issue Dec 3, 2024 · 2 comments
Open

QNX Support #1914

JaiXJM-BB opened this issue Dec 3, 2024 · 2 comments

Comments

@JaiXJM-BB
Copy link

Feature

Add cross-compilation support for the QNX operating system to gtsam.

Motivation

QNX is an industry standard real-time operating system for embedded systems, particularly for vehicles, featuring safety focused features. It has also recently been made free for non-commercial use through the QNX Everywhere program, aiming for students, researchers and hobbyists to experiment with the OS.

Given that gtsam is a mapping library with many features relevant to autonomous vehicles (Mapping, SLAM, etc.), it would make sense to include some support for the free version of QNX (8.0) natively.

Pitch

As a QNX employee, I have done some work on porting GTSAM on our fork over at https://github.com/qnx-ports/gtsam. It still needs a little more time ironing out floating-point errors in test cases and figuring out the ideal way to run tests (given that ctest doesn't work well for cross-compilation).

The majority of changes so far have had to do with installation location while cross compiling and can all be done in a small amount of if(DEFINED)/ifdef type statements that would not affect compilation for other environments.

I wanted to reach out and ask whether an upstream from our fork is something your lab would be interested in accepting?

@varunagrawal
Copy link
Collaborator

Hi @JaiXJM-BB. That sounds really cool. Do you think it would be possible to cross-compile using only CMake changes? Unfortunately, AFAIAA none of us here are familiar with QNX so maintenance and updates would have to be handled by you or the community.

Alternatively, having your fork be the de facto version for QNX would be a good solution. I've seen this done for Arch Linux where someone else has been handling keeping the AUR packages up and running.

@JaiXJM-BB
Copy link
Author

Hi @varunagrawal ,

I'm currently in the process of updating the port to be in line with the develop branch as I started on release 4.1. So far, all the changes I have made have been in CMake files, mostly handling test installation so that they are installed to a staging area and then can be cloned onto a target. There's a few other cases there which I will detail when I make a pull request.

The only exceptions to this have been a few tests which had a scope conflict (which I noticed was fixed in the develop branch for another system, via a preprocessor definition), and one partitioning test in which our case matched the expected output of MacOS instead of the default. For these, I've edited the relevant if defined() statements to include QNX as well.

Assuming these two types of changes are all I end up needing after bringing the port up to the develop branch, would that meet your requirements? If so, I'll open a PR once I verify all tests are running correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants