RFC: what happens when c_args/ld_args come from multiple locations? [skip ci] #6362
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Combinatorial explosion and... some documentation gaps?
The main confusion is:
Some
c_args
definitions append to each other, others override each other. Which/when/why/how?While this is technically a PR, consider it more like a github issue with a lot of sample test code.
I searched the documentation for all the different ways to define
{cpp,c,ld}_args
and the relationships between them. However what I found was scattered across the documentation: no single, high-level list or overview. It seemed sometimes incomplete.I searched github for the same topic (some links below) but that didn't really help either because most of github is or was of course "work in progress" (the difference between "is" and "was" not always obvious) For instance #4767 states:
Except:
-D
,project(default_options: c_args...)
,executable( c_args, native:false)
,...Then I searched for some sort of "
c_args
test code". That would be in a less natural language but never obsolete as github issues and PRs become. As I couldn't find anyc_args
test code, I wrote this one. While tedious, this helped me understand some of the situation better.I'm not sure exactly where to take this next.
A new, "<lang>_args hub" documentation node with an organized list of pointers would probably go a long way.
Another good thing would be to upgrade this prototype test code to fully automated tests and it's probably not too far from that, except for this difficult question: which particular combinations of c_args inputs should be tested? Can't test everything due to the number of locations and the combinatorial explosion.