Open VGRSTM opened 2 years ago
I personally prefer explicit list of files from two reasons:
but I know also people who prefer reduced maintenance effort and use wildcards as much as possible. Open CMSIS Pack should probably support wildcards and let user to decide.
This topic has been identified as part of CMSIS-Build Gap Analysis
@DavidJurajdaNXP & all, already shared Thanks some other comments, I'm fully sensitive myself to build reproducibility but I would back promote my point which is OpenCMSIS proposal is moving and we have now 2 "containers" to support workflow:
I foresee myself reproducibility concerns being addressed Thanks .cprj & project source control. .yml contributions may then support other stuff which is project description in the light of PLM. This way I'm thinking .yml data may allow mix of exact and more loose descriptions enabling various user and integrator flows. I'm only pushing here to get pattern support do not mean you're forced to use it but devtools have to support it in sync. with yml schema update if we agree on
No problem with the concept of wildcards for files here. However, several observations and questions:
**
, [abc]
, a*b
, a?b
etcfor-type
and not-for-type
.pattern
? Could we just expand files
instead? If not, how do files
entries interact with all of the other inclusion and exclusion mechanisms?This is all getting rather complex, and needs clear documentation to enable reliable implementations to be built.
@mark-edgeworth considering we are in agreement on principle (good !) yes let's move to specifications refinement. To my view:
Myself I like https://code.visualstudio.com/docs/editor/codebasics#_advanced-search-options especially because **
is nice discussing about file pattern here
I'm thinking prior being able to apply any exclusion pattern we have first to build a list to exclude against. So I would promote includes (aka. source_patterns
) first to build resolved files list. Next I would process excludes (aka. exclude_patterns
) to remove related resolved items from resolved includes list.
My guess is as to support for-type
and not-for-type
as file
is supporting
I'm thinking adding source_patterns
support to files
is right way.
Same I'm thinking to add exclude_patterns
pattern support to files
.
Back to 2. file
have to be added to includes resolved file list and exclusion pattern to applied on top of.
groups: - group: main files: - file: ./src/main.c - pattern: ./src//*.c - pattern: ./src/*/.cpp - exclude: ./src//*.md
- group: func1 files: - file: ./func1/src/func1.c
Even better to me as end user ... just get rid of pattern
... file
supporting regular expression :-)
groups: - group: main files: - file: ./src/main.c - file: ./src//*.c - file: ./src/*/.cpp - exclude: ./src//*.md
- group: func1 files: - file: ./func1/src/func1.c
According my view sounds like not so complex. I'm pushing to get "only" files
extension. Let's think this way:
devtools
we have some API which is promoting getFiles(...)
function returning collection of file
items (ok possibly some per group
filter or ...)getFiles(...)
core process.While I like the idea to not distinguish file from pattern, do people care that a pattern potentially describes multiple files (singular vs. plural).
Do we need a precedence in processing or is it done sequentially? a) process 'file' and 'pattern' entries before 'exclude' b) process entries sequentially
Only process entry if for-type/not-for-type allow
optimize, debug, defines, undefines, add-paths, del-paths, misc are not supported for "exclude"
What other "dependencies/context" do people see need to be considered?
@jkrech
To my view we have to update nothing to current devtools
implementation what means to keep current type/not-for-type, misc. etc. processing related to file
.
Based on current processing we are at a point building some internal lists.
Just consider:
file
is same than adding multiple explicit file
items got Thanks pattern resolutionMy first guess schema is:
We may end up with such usage:
Per current https://github.com/Open-CMSIS-Pack/devtools/blob/a9919425f6554425e8723aee5bf7a9b299387e95/tools/projmgr/docs/Manual/Overview.md#groups-and-files proposal source description is file based. It sounds like a pain from an IDE context. Such assumption is fully valuable if build reproducibility but purpose of .cprj then. Considering project manager, so .yml contributions, I would be please to add source patterns and related exclude patterns addon. Up to project manager process building *.cprj file to compute a runtime such patterns leading to a file based proposal.
groups:
- group: main
files:
- file: ./src/main.c
source_patterns:
` - pattern: ./src//*.c- group: func1
files:
- file: ./func1/src/func1.c
Note: Keywords / schema to be discussed just promoting high level requirement here