Implement `cartesi coprocessor build`

[endersonmaia]

Implement a cartesi coprocessor build command that prepares a rootfs for the cartesi machine and its CARized version so it's ready to be published to IPFS.

Steps:

• Deprecate current cartesi build command
• Reuse same process of the current cartesi build
• Move current cartesi build to cartesi rollups build
• Add a new cartesi coprocessor build with extra CARize process

[Nonnyjoe]

I'll also like to work on this, @endersonmaia

[endersonmaia]

@tuler I'd like your input here.

I'm not sure if there's much difference in the way cartesi build works that we'd need to split between rollups build and coprocessor build.

Also, a root cartesi build command could discover for which framewoek to build based on the framework= configuration, but that's not working yet, and I don't know if it's gonna move forward (#174).

The question is: Do we really need to split the build command now?

/cc @stskeeps

[tuler]

As far as I understand the coprocessor-cli is actually just calling the cartesi build, right?

Also remember we have the cartesi.toml build configuration

[stskeeps]

Should be same build process, can maybe argue carize is a publishing step

[tuler]

can maybe argue carize is a publishing step

Yeah. With rollups the rollups deploy is also a "publish".
Currently we copy the image to inside the docker container.

[endersonmaia]

About deploy/publish, let's discuss at issue #230

[Nonnyjoe]

Should be same build process, can maybe argue carize is a publishing step

Yeahh... I will say the only difference between them is the Carize step.
But won't that be too much going on in the publish command, generating and also uploading the car files

[Nonnyjoe]

We could modify the build command to identify which framework it's being run on (maybe through the framework flag), then execute the carize step if the application is a coprocessor app else it skips it.

This was we still maintain the regular cartesi build command

[endersonmaia]

Yeah, but I'm not sure this framework= is gonna move forward.

[Nonnyjoe]

Yeah, but I'm not sure this framework= is gonna move forward.

Ohhhh, Any specific reasons why?
Also, what's the way forward?

[endersonmaia]

You can start with `coprocessor build`while we decide what to do with the `framework=` config file support. Em dom., 13 de abr. de 2025, 08:46, Idogwu Emmanuel Chinonso < ***@***.***> escreveu:

…

Yeah, but I'm not sure this framework= is gonna move forward. Ohhhh, Any specific reasons why? Also, what's the way forward? — Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAC4RJ76HLAYADZ24UWBL2ZJFAHAVCNFSM6AAAAAB2AADDR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJZHEYTSMRYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***> *Nonnyjoe* left a comment (cartesi/cli#229) <#229 (comment)> Yeah, but I'm not sure this framework= is gonna move forward. Ohhhh, Any specific reasons why? Also, what's the way forward? — Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAC4RJ76HLAYADZ24UWBL2ZJFAHAVCNFSM6AAAAAB2AADDR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJZHEYTSMRYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>