yes, it's a good start! getting my feet wet but I'm very enthusiastic about the potential
I should probably prevent this tho, thanks for pointing it out
oh, good point. I did not pay attention to this detail! Of course, it makes sense! Thanks for the clarification
(sorry about the lag with the PR, I had a lot of bugfixes to push on score, now I'm on libossia until the end of the week !)
I'll try to make another round of testing
but if you can try this example, I think that it maps to what you want : https://github.com/ossia/libossia/blob/feature/async_protocols/examples/Network/OSCQuery_bridge.cpp
@thibaudk for the SC patches I think that you should rebase on top of current SC master branch prior to anything
git remote add supercollider https://github.com/supercollider/supercollider
git fetch supercollider
git rebase supercollider/master
(and this part has not been tested at all also)
and.. is there anything i can do to help?
Which can then be polled / run / ...
It uses asio behind the hood
@jcelerier have you all considered conan for managing dependencies? I put together a basic recipe and pushed a branch, it uses conan to get/build boost there are a number of other libossia deps that could go this way too..
here is an example cmake file that shows the usage of a version of libossia i packaged with conan: https://github.com/Cycling74/libossia/blob/xnor/conan/examples/Conan/CMakeLists.txt
the branch https://github.com/Cycling74/libossia/tree/xnor/conan
here is an example cmake file that shows the usage of a version of libossia i packaged with conan: https://github.com/Cycling74/libossia/blob/xnor/conan/examples/Conan/CMakeLists.txt
the branch https://github.com/Cycling74/libossia/tree/xnor/conan
hi ! yes, and I had opted out against it when I tried for the following reasons (my notes are from 2019 so it could be time to revisit though):
- not possible to parallelize the download of dependencies (when I had tried to port ossia it took something like 10x longer than git clone --recursive -j16 which is really not good for CI)
- multi-configuration builds seemed complicated
- made it hard to "just" clone the repo, open the CMakeLists.txt in the IDE we use (QtCreator) and be ready to go, in particular I quite often have students doing internships, group projects, etc... on the code and from experience every additional step makes it much harde for them to get started with the actual work. Though https://docs.conan.io/en/latest/howtos/cmake_launch.html could alleviate that a bit.
yeah, packaging is as easy as
We're planning to make a public repo for our shared work, which is where i was planning to put libossia when I create the package.. but you'd need to get your own or access to some other public one for automating publishing for your organization
conan create . user/channel the issue is publishing though. you need to have a conan repo you can write to.We're planning to make a public repo for our shared work, which is where i was planning to put libossia when I create the package.. but you'd need to get your own or access to some other public one for automating publishing for your organization
jfrog provides a free tier for conan repos.. i'm using that right now, but they require activity every 2 weeks or so, download or upload, which sometimes is unreasonable, if you don't release often you mostly just used cached installs
but, publishing is also easy once you have a place to put your packages
I do get the multi-config thing too, i'm not sure how to delay the conan download/build/install until after a configuration is selected.. so maybe migrating more deps to conan doesn't make sense for this project, but boost (as I already did) considering its a requirement for all the builds, might.
once nice thing on that though, conan downloads binaries if there are binaries for your configuration already published (for instance, static boost library for clang8 macos), and the packages are cached in their own place so you take a hit the first time you do a build but after that, if you don't change versions or configurations, things move pretty fast
@avilleret do you think we could :
- merge the github-actions branch
- rebase async_protocols on it (I'll do it)
- merge that one into master (I just have a couple commits to push before that but it should be done soon)
- tag a new major version :D
.. but you'd need to get your own or access to some other public one for automating publishing for your organization
yep, I used to have a jfrog one but it seems it has been deleted with their recent change heh
hosting one should not be a problem though
but I think that it should soon be mergeable which will simplify that