Remove dependency on isatty() for Zephyr #458
Conversation
|
Sorry, this one looks messed up too. This all has to do with the confusing situation of micro-ROS being a fork of ROS, and my using that as a starting point (because GitHub won't let me make my own fork of the real ROS2 repo unless I delete my microROS fork). |
* micro-ROS changes over dashing Feature/add security directory (micro-ROS#1) * Added security directory * Updated security directory Feature/avoid filesystem and allocation (micro-ROS#2) * Included RCUTILS_NO_FILESYSTEM and RCUTILS_AVOID_DYNAMIC_ALLOCATION * Added no filesystem options * Default allocators write access * Avoid dynamic allocation and no filesytem on error handling * Typo * New flags for filesystem and avoid dynamic * Error handling template * New allocator approach Add test_security_directory test from rcl. (micro-ROS#3) Merge pull request micro-ROS#4 from micro-ROS/feature/zephyr_fixes Feature/zephyr fixes CMake refactor (micro-ROS#5) Update approach (micro-ROS#6) * Update approach * Remove target_compile_definitions and refactor flags install * Added RCUTILS_NO_FILESYSTEM on new functions * Added RCUTILS_NO_FILESYSTEM on new functions Co-authored-by: Pablo Garrido <pablogs9@gmail.com> Updates 17092020 Fix atomics 64bits (micro-ROS#9) * micro-ROS changes over dashing Feature/add security directory (micro-ROS#1) * Added security directory * Updated security directory Feature/avoid filesystem and allocation (micro-ROS#2) * Included RCUTILS_NO_FILESYSTEM and RCUTILS_AVOID_DYNAMIC_ALLOCATION * Added no filesystem options * Default allocators write access * Avoid dynamic allocation and no filesytem on error handling * Typo * New flags for filesystem and avoid dynamic * Error handling template * New allocator approach Add test_security_directory test from rcl. (micro-ROS#3) Merge pull request micro-ROS#4 from micro-ROS/feature/zephyr_fixes Feature/zephyr fixes CMake refactor (micro-ROS#5) Update approach (micro-ROS#6) * Update approach * Remove target_compile_definitions and refactor flags install * Added RCUTILS_NO_FILESYSTEM on new functions * Added RCUTILS_NO_FILESYSTEM on new functions Co-authored-by: Pablo Garrido <pablogs9@gmail.com> * Initial changes * Add hashing and lock pool * Updates Co-authored-by: Jose Antonio Moral <joseantoniomoralparras@gmail.com> Fix atomics 64bits (micro-ROS#9) Updates 09102020 * Release micro-ROS Foxy (micro-ROS#8) Update Cleaning Update Update filesystem Updates Adjust logger level Remove build warning (micro-ROS#10) * Avoid not used warnings * Update Reduce error handling static size (micro-ROS#14) (micro-ROS#15) This reverts commit befc608. Reduce error handling static size (micro-ROS#14) (micro-ROS#15) Signed-off-by: Pablo Garrido <pablogs9@gmail.com> (cherry picked from commit 1176652) Co-authored-by: Pablo Garrido <pablogs9@gmail.com> Revert "Revert "Install headers to include\${PROJECT_NAME} (ros2#351)"" This reverts commit 4546892. Fix atomic 64 b description (micro-ROS#17) (micro-ROS#18) (cherry picked from commit 85efa4a) Co-authored-by: Pablo Garrido <pablogs9@gmail.com> Add fork checker for humble Signed-off-by: Pablo Garrido <pablogs9@gmail.com>
)" This reverts commit 24431ba.
Signed-off-by: Dave Rensberger <davidr@beechwoods.com>
|
I'd like to submit these changes, but I don't know if that's going to be possible until I can delete my GitHub fork that was originally based on micro-ROS/rcutils and create a new one that's based on ros2/rcutils. No matter what I do, my PR ends up being polluted with all sorts micro-ROS changes that I didn't intend to submit. Should I just close this one for now? |
You shouldn't need to delete. Your fork can be called anything; I would suggest re-forking |
No, GitHub doesn't seem to allow that... If I try to create a fork of ros2/rcutils, GitHub presents me with a message saying "No available destinations to fork this repository." Reading up on this, it seems that it really is an obscure limitation of GitHub https://stackoverflow.com/questions/12338240/how-can-i-fork-the-original-repo-when-ive-already-forked-a-different-fork I'm sure that if I were especially adept with the rebase command, there'd be some way to clean all of the micro-ROS "pollution" out of the "rolling" branch on my fork of their fork, but I'm only marginally proficient with "git rebase". I honestly think that MicroROS should be its own separate repository, rather than a GitHub fork of yours, since they consider themselves to be a separate project. They could still keep in sync by pulling updates from yours. |
The Zephyr OS doesn't have an isatty() function, so that dependency needs to be conditionally removed for Zephyr.