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 · 1 comment
Open

QNX Support #1914

JaiXJM-BB opened this issue Dec 3, 2024 · 1 comment

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.

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