General layout example for cloud compilation
Theodore Borromeo last edited by
Hey Onion community. Does anyone have an example of valid files that are supposed to be contained in the zip file you drag and drop into cloud compile? Is there a tutorial of what kind of make system we're to expect on the backend when cloud compilation goes down?
Also, can we possibly get a web frontend for the cloud compile that will expose some build options for wrt, funnel those options as environment variables to a docker client, and build custom firmware images on the fly that can then be shuttled over to dev devices via onion cloud integration? The container could easily be built from instructions at: https://wiki.openwrt.org/doc/howto/obtain.firmware.generate
and then, onion could replace critical bootstrap code by unpacking and repacking resultant firmwares (or embed their build instructions into their docker container directly) before they go to device such that onion cloud connectivity is maintained. It would be even more dope if the base firmware could know to put itself into recovery mode before flashing, try to flash a new firmware to a removable usb stick, and if the 'flashing' fails, all a user has to do is remove the usb stick & reboot to get back to a known good configuration. . .
anywhos: where is there more info for cloud compile?
@Theodore-Borromeo wow lots of stuff here, i'll just cover the Cloud Compile stuff for now.
Zip File Structure
The zip file that you input for Cloud Compile should contain source code and header files. For C projects, the source code files must end in
.cand for C++ projects, the source code files must end in
.cpp. The file structure doesn't matter, the backend will figure everything out.
Currently, the backend will take your source code and build a single target. We're working on allowing you to select which dynamic libraries you want to be linked with your project. Expect that late May/early June.
Further down the line, we'll have project types that allow your own makefile. No concrete timeline for that yet but sometime in the next few months.
Still working on the documentation and example code, but expect that soon! I'll make sure to update the community when the documentation is available.
For now, make sure to check out the tours provided by the button, note that the tour content is different on every page!
Yep, there's a lot of opportunity to do some amazing things with the Cloud Compile, we do plan on greatly expanding the features, stay tuned
Theodore Borromeo last edited by
@Lazar-Demin as always, thanks for the response! I literally keep this open waiting for developments as they occur
I am assuming that this information will come, but you seemed to point out something I was worried about:
I have a bunch of static and/or dynamic libraries I want to link with, but without control of a makefile, I can't ensure the resultant application is built/linked properly. This is a slight downside, but, I can just build something that requires static libs myself, at that point, as I'd have more capabilities myself then cloud compile would actually give me.
To that end, I just realized that I could extend the docker container I made up for nodejs compiling to utilize the toolchain and create a arbitrary programs given a directory filled with makefiles/sources/static libs.
Nominally, I could mount a directory of a project via -v flag to draw in any git repo for building in my toolchain container. I could then have a build hook/script within the container or in the git repo that, post-build step, POSTs the results to onion cloud for loading and installation to the omega. This would entail that I also, along with mounting the project directory, perhaps mount the credentials directory for the specific API key I want to post to. . .
Love it! Now that onion cloud/ubus/api integration is up, I feel the community can move at a much faster pace. I feel, though, that perhaps you should invite and open up your design meetings to members of the community (as much as you can without sacrificing your competitive edge) so that community advocates can do this sort of documentation and whiteboarding for you I mean, I'm happy to spitball all my good ideas and all, but I feel you all should get to your core business and allow critical functions to be taken over by your dedicated and fanatical community.
Keep up the good work!