Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[csolution] files with category doc are not in the generated *.cbuild.yml #1155

Closed
tarek-bochkati opened this issue Oct 19, 2023 · 7 comments
Assignees
Labels
bug Something isn't working

Comments

@tarek-bochkati
Copy link
Contributor

Describe the bug
this might not be a bug, could be a wanted behavior ...
I have a cproject file:

  • containing a README.md file with doc as category
  • or referring to component with doc file

in the generated *.cbuild.yml, only source and header files are resolved.

To Reproduce

  • add a README.md to *.cproject.yml file
  • then convert to *.cbuild.yml
  • check the generate *.cbuild.yml

Expected behavior

  • the README.md should be in the generated *.cbuild.yml

Environment (please complete the following information):

  • cmsis-toolbox
  • Version: 2.1.0
  • OS: windows
@tarek-bochkati tarek-bochkati added the bug Something isn't working label Oct 19, 2023
@brondani
Copy link
Collaborator

brondani commented Oct 19, 2023

Indeed this is the intended behaviour. Documentation files are not relevant for the build which is the scope of *.cbuild.yml files.
Edit: This is the behaviour concerning files described in components, but not for user files. The mentioned README.md in *.cproject.yml appears also in *.cbuild.yml:

build:
  groups:
    - group: Documentation
      files:
        - file: ./README.md
          category: doc

@tarek-bochkati
Copy link
Contributor Author

@brondani, do you think that is interesting to align both behaviors of user files and component files ?

IMHO:

  • if we consider that the *.cbuild.yml is a build artifact only, then no need for doc files
  • if we consider that the *.cbuild.yml is a lock file and it contains the resolved project state, then docs should be part of it (incl. component docs)

@jkrech
Copy link
Member

jkrech commented Oct 20, 2023

We have moved on from the idea using *.cbuild.yml as a lock-file.
In #1122 -> introducing <csolution-name>.cbuild-pack.yml instead.

@brondani
Copy link
Collaborator

@tarek-bochkati Yes for consistency we should definitely align the behavior.
For completeness I would vote to print all files, leaving to consumers to filter the categories to their use cases, but this could inflate the *.cbuild.yml files with irrelevant data.

@tarek-bochkati
Copy link
Contributor Author

@brondani I would vote also to have all files in the *.cbuild.yml
since I value the *.cbuild.yml as a resolved state of the project, and I hate to force other developers to do to resolve again the project just to extract files like the documents.

@jkrech jkrech changed the title files with category doc are not in the generated *.cbuild.yml [csolution] files with category doc are not in the generated *.cbuild.yml Oct 24, 2023
@LMESTM
Copy link
Contributor

LMESTM commented Nov 29, 2023

Hi @jkrech @brondani
for my information, have you come to a conclusion and a proposed way forward on this topic ?

@brondani
Copy link
Collaborator

@LMESTM I believe we agree all files must be listed in the *.cbuild.yml alongside their categories. I am scheduling this GH issue to be addressed for the next release.

Hint for the implementer: make use of RteTarget::GetFilteredFiles.

@jkrech jkrech assigned soumeh01 and unassigned edriouk, brondani and soumeh01 Mar 12, 2024
@soumeh01 soumeh01 closed this as completed Apr 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
No open projects
Development

No branches or pull requests

6 participants