fix: improve portability of source tree#8
Conversation
- fix: move submodules to https transport for portable clone - chore: add C++ support to build - fix: move to C++ quick_args_parser and remove non-portable argp.h include
|
Hey @aronson thanks a lot for your PR! This cmake stuff is all a bit magic to me, so I'm happy to take your contributions. Can you verify that your latest version works on Mac in Docker? The Dockerfile doesn't seem to build anymore due to the If I revert that, the Dockerfile builds but doesn't run anymore, due to the final binary not missing |
|
Looks like the slipstream-picoquic Dockerfile was already broken in the original master branch. It still throws errors in make check you get with my modifications. The errors are different though it would seem! Adding the now-missing signal.h include in my new code gets me to other errors. I'll check the rest and try to fix it for you but I can't guarantee I'll be able to fix it. The slipstream Dockerfile itself is fine even with my changes (other than a non-static libcpp as you noted). Stay tuned... |
…r (and other) builds
|
My findings were Docker was broken out of the box in the I think part of the reason the original As for the missing Let me know how it looks now 🙂 P.S.: I considered porting to meson for my own reasons, but I figured it would be kinda rude to change build systems under you with my first PR. If you're open to that, it's much easier to use than CMake in my experience. I re-tooled Apotris ages ago away from make to meson and it gave us bonkers level of portability. |
|
Oh hold up, adding the static link to this breaks Termux! Lol! Hold off, I need to fix that, one moment... It would be better to ask for it in the Docker build's own configuration... |
|
OK that fixed it all. I guess you'll need to only use a static link to the c++ library in Docker. Tested and working as expected in Docker, Termux, bare-metal Linux, and macOS. |
|
Amazing, indeed easier to just force static in Docker only! I'll have to look into the release GH workflow, but am holding that off if you're planning to move build systems. Would you also need to change over picoquic, or can you include cmake subprojects? |
|
You can include CMake projects (though it's a little poorly documented). I leverage this in that other project to great success for an unreleased feature branch. I'll take a stab at it soon and open a PR leveraging a new release flow for you when I can! Stay tuned... |
Hi, I tried to run this on mobile using Android and Termux, as well as run this on macOS with my Mac and Apple clang, and it didn't build.
I updated a few things to do this:
pthreadinvocations to support macOS when__APPLE__is defined by the compilerargp.himport and instead leveraged a header-only library to replace it. Thatargp.hheader isn't available on macOS nor Android.ANDROIDwhen used in this config, so I instead relied on the appropriate built-in definition per the POSIX specification-fno-exceptionflags from picoquic's CMake definitions as it broke the build given quick_arg_parser leverages C++ exceptions.gitignoreto ignore some files that were bugging me when working on thisEDIT: I also tested it, of course.
Server confirmed working on:
Client confirmed working (including multipath) on: