Support measures for snap developers

[nes]

Hi!

Regarding CI/CD toolchain, how are developers of snaps for ctrlX CORE currently supported and what are the plans for support?

For example:

• snap templates: creation of preconfigured projects via simple dialog, for different languages (e.g., incl. respective SDKs and libs) or purposes (e.g., frontend development); directly from github; e.g., using cookiecutter
• build server for remote snapcraft builds (for different platforms, languages), also as alternative to time-consuming building of dependencies (e.g., of python libs) on alternative hardware like Raspberry Pi; build directly from github
• sponsoring of documentation on OSS projects relevant for ctrlX development (e.g., snapcraft.io)
  

Thanks!

[CodeShepherd · Accepted solution]

We are already providing a SDK that is further improved with each release. This includes prefinished and buildable examples of snaps for the ctrlX CORE. Included is also documentation for the different interfaces that can be used. At the moment this SDK is prototype state and can found in our collaboration room and can be downloaded by permitted customers.

Build servers is a topic we are actually discussing about, but there no state to public right now.

We mainly rely on the OSS documentation and using its interfaces. So in most of the cases we are linking to the official website. Our OSS code will be published on Github as well as e.g. JSON schemata.

[thomas-jung]

Hi there, 

we know the SDK and successfully worked with it to build and deploy some simple, some more sophisticated Snaps. Anyway - with strong background in computer science but only very little exprience in ARM development we faced (and solved) some hurdles during the development, which we think should be lowered to motivate future customers with a similar knowledge background to intensive use the platform to develop custom applications on ctrlX. Please do not take this as a criticism, we know the platform is under development - we only formulate a wish list.

So: It would be very nice, if there was some kind of project template generator or template pool. If i want to start a new snap project, i have to choose: 

What do i want to have? 

• Backend-App? 
  • Language (one of): 
    • Go
    • Python
    • C/C++
  • Anyway: 
    • There is an exemplary epp prepared which builds and runs directly
      • Go: 
        • go build
          • ctrlxsdk and ctrlxsdkgo-Wrapper downloaded as go-modules
        • ./<projectname> [clientURL] [serverURL] → runs, prints "Hello World" and reads something from the DL
      • Python: 
        • pipenv install 
          • gets the ctrlxsdk and ctrlxsdk-py-Wrapper as pipenv packages
          • creates a working pipenv environment
        • python main.py [clientURL] [serverURL] → runs, prints "Hello World" and reads something from the DL 
      • C/C++
        • CMake <projectname>
          • ctrlxsdk downloaded / extracted automatically 
          • Compiles
        • ./build/<projectname> [clientURL] [serverURL] → runs! 
• Web-Application? 
  • If yes:
    • The webapp and the backend have some exemplary code to connect a button and some input text field to a method in the backend app. 
    • The webapp contains the webcore template and compiles without any further modifications. 
    • npm install? 
    • Prepared Backbone in Go / Py (see above)
      • Compiles / runs directly 
      • Provides access to Datalayer
    • Browser localhost:8080 shows web app
      • Exemplary call to backbone is implemented
• Development-Platform, Target Platform? 
  • Arm / x86 / amd64
    • For any combination there will be build scripts, so that compilation / cross compilation works without further modifications
    • Alternatively: Just choose development platform and snapcraft automaticalls builds separate snaps for all relevant possible target architectures 
• Build remotely? 
  • If cross compilation is hard to realize easily on the developers machines, it might be an option to offer some build environment in the form of some CI-pipeline on a rexroth hosted gitlab server. 

Lots of work, sure. We think if you really want to motivate non-rexroth and probably even non-classical-machine-builder developers to build ctrlX-apps for new use cases, the technical hurdle to get started has to be very low.