cpackget dependency question

[jeromecoutant]

Hi

My CMSIS_PACK_ROOT is well specified, but I couldn't use cbuild and cbuildgen in standalone:

error cbuild: cpackget was not found

Can we consider that cpackget is not "mandatory" to call cbuild application ?

[fred-r]

In my opinion, OpenCMSIS tools must remain "atomic" and independent.
So cbuild should only build.
If a logic requiring cpackget is implemented (checking available packs for instance) then it should be an upper level service.

Or shall we consider that cbuildgen is the atomic service and that cbuild is already an higher level service ?

The README states:
"This utility allows embedded developers to orchestrate the build of CPRJ projects using cbuildgen, cpackget, cmake and ninja."

==> cpackget is indeed listed.

But to me cbuilgen+cmake+ninja make sense it has a consistency.
cpackget is a different beast in my opinion providing different services.
Why using it here ?

[brondani]

cbuild does conceptually the same as its predecessor cbuild.sh, but it does not need bash anymore while still being multi-platform.
It's a front-end (high level service if you prefer) to conveniently call several tools to build an embedded project, even downloading packs if needed - for this reason it requires cpackget.
cbuildgen is always the atomic service. How you set your pack repository, lint the project, call CMake and other underlying build services - not restricted to ninja - is fully customizable and does not has to be done via cbuild.
Having said that, cbuild should be useful for most typical use cases so good suggestions for improvements are welcomed.

[jeromecoutant]

Maybe move
https://github.com/Open-CMSIS-Pack/cbuild/blob/main/pkg/builder/builder.go#L194
code to
https://github.com/Open-CMSIS-Pack/cbuild/blob/main/pkg/builder/builder.go#L278
?

[fred-r]

@brondani : but how did you manage to pass the csolution step if the packs are missing ?
To me this is redundant.

[brondani]

@jeromecoutant yes I understand you don't need cpackget if you don't have missing packs, we can certainly improve that check.

@fred-r

but how did you manage to pass the csolution step if the packs are missing ?

cbuild does not call csolution, it just takes a cprj as input, it does not matter how it was generated.

I see the potential of having a front-end with a wider scope including project management (csolution) capabilities, I believe it's worth to be discussed.

[fred-r]

@brondani : I do not think it is the role of OpenCMSIS to provide front-end tools.
My point is really to have clear scopes for each tool.

I am interested in having cbuild "wrapping" the build so abstracting cmake+ninja+compiler

I am not interested in having cbuild doing more than this.

I think that it is at the cprj generation stage that packs can be checked.
To me, the scope of cbuild is only to build : something is missing ?
Fine, it fails gracefully.
If you start checking the packs then you may check the user files presence...and so on...and we do much more than building.

To me the OpenCMSIS tools are here to be a "reference" to check that our implementations are respecting the spec.
So if I implement my own cbuild, I want it to be on par with your cbuild.
If your cbuild does more than building then I do not know if I have a difference if it is:

• because my tool does not respect the spec
• or because your tool is doing more than the spec

So let's say I provide a cprj with missing packs in the environment:

• your cbuild will download and build
• my cbuild will fail
  Then I will have to wonder : is it me not processing the cprj properly or is it Daniel's cbuild being clever enough to cope with problems that are not related to build?

[brondani]

@fred-r While keeping the separation of concerns among the atomic services, I don't see why a reference front-end cannot use all available tools to provide the best possible user experience. Anyway as I said currently cbuild does the same as the predecessor cbuild.sh, there is no change in scope.
Feel free to bring your concerns to the Open-CMSIS-Pack meeting audience so we can have clearer directions.

[fred-r]

Just clarifying my position before we discuss it:

I do not want to prevent you from doing whatever can be helpful in a front-end, I agree with you on that.
But, I also need an "atomic" service with as few dependencies as possible to build.
And here, to me:

• cbuildgen is not this atomic service because Cmake and Ninja and the compiler are also part of the bare-minimal setup you need to compile an OpenCMIS project.
• cbuild could be this candidate

So, my point is more to say:

• let's keep cbuild as a bare-minimum build service for OpenCMSIS projects
• if needed, we can create a front-end that does more than just building like checking the packs, maybe detecting also discrepancies between RTE folder content and components versions...etc...

[brondani]

@jeromecoutant Please check if the CMSIS-Toolbox 0.10.1 works as you expect:
https://github.com/Open-CMSIS-Pack/devtools/releases/tag/tools/toolbox/0.10.1
Thanks

[jeromecoutant]

Yes, issue can be closed
Thx