Packaging an Atoms module for distribution from Atoms servers, either public online or local internal repository

Tools Atoms packages
1

Hi all,
I wonder whether it exists already somewhere an up-to-date description of the details about module packaging (like a wiki page on that topic), how to move from the module just being built from source (ie loader.sce in the module root directory, .bin in macros, help files generated etc… ) to an arranged archive ready for binaries distribution only, with appropriate names, checksum, for integration on Atoms server, either public online or local internal repository ?

Thanks,

David

2

Hi David,

This is indeed a very good request. I have some script that cleans the build and generates a package in a CI file. This could be done quite easily by hand to:

  • keep only .dll / .so on src/ and sci_gateway/
  • remove the help/
  • create a tarball starting with name-version/ as a root directory.

Another approach would be to have a tbx_package() macro within Scilab that cleans and produces a zip file or a tar.gz depending on the platform.

3

Hi David

I wish there would be a write-up which is up to date. This is the latest instructions, maybe still valid:

https://www.scilab.org/build-a-toolbox

This is a bit older, but also more rich on information:

https://scilab.gitlab.io/legacy_wiki/howto(2f)Create(20)a(20)toolbox

This I believe is the best we have for now.

Best regards,
Claus

4

Hi Claus,
thank you for the links, especially the second is also pointing out How to create a local repository which adresses partially my specific issues about how to package the module (once properly developed) in order to distribute it easily from a private Atoms repository.
They are some new issues ( #16971and #16961) raised in scilab.gitlab that emphasizes the documentation about this should be updated/upgraded. The idea would be to make detailed descriptions consistent with the Scilab versions evolutions, including latest Scilab 2023.0.0.

David

5

Hi Clément,

reading your message and the CI file, I wonder whether anyhting changed around atomsInstall() in Scilab 2023.0.0 compared to previous Scilab version, especially regarding the naming rules for archive files ??

For the time being in our local ATOMS repository, we have such syntax in windows description file which is working fine for installation request from windows machine with Scilab version <=6.1.1 :

sourceName: toolbox_xD_2.2.1.zip
sourceMd5: 6b7a4fdb8a5e5519fd9d9d3ee3fbbbc4
sourceSha1: 8c75b7fb5410a0ba7cb4de1a6bfce1e44c16e83f
sourceUrl: /modules/toolbox_xD/2.2.1/files/toolbox_xD_2.2.1.zip
binaryName: toolbox_xD_2.2.1.bin6.x64.windows.zip
binaryMd5: 930ddb48587887fa6727e33898dbbd51
binarySha1: 8e862fcd14befbb029a9359e67d4346039545efb
binaryUrl: /modules/toolbox_xD/2.2.1/files/toolbox_xD_2.2.1.bin6.x64.windows.zip

while atomsinstallation is failing with request from machine Scilab 2023.0.0 (manual installation from local archive files, source or bin archives, is ok in SCI2023.0.0, so it’s only a matter of atomsinstallation ) : i raised issues in gitlab on this and achieved some progress however still not running properly, maybe due to naming conventions ?

Trying to guess from your message and CI file, should I rather rename the source archive file as toolbox_xD-2.2.1.zip and bin archive file as toolbox_xD-2.2.1-x64windows-bin.zip ? (changing separator from . to - as the order of the “fields” in the name ?)

In addition create specific version of the toolbox (2.2.2 or 3.0.0?) to cope with this changes for ScilabVersion: >= 2023.0.0 ?

6

You are correct, there is a change in the 2023.0 release. IMHO this is more related to the Url field handling.