RFC: what happens when c_args/ld_args come from multiple locations? [skip ci] #6362
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…skip ci]
Combinatorial explosion and... some documentation gaps?
Consider this is as a github issue with a lot of code.
I tried to find in the documentation all the places {cpp,c,ld}_args
could be set and the relationships between these places. However what I
found was scattered in the corresponding places - no single, high-level
list or overview - and seemed sometimes incomplete.
I searched github for the same topic but that didn't really help either
because most of it is or was of course "work in progress" (the
difference between "is" and "was" being not always immediately obvious)
For instance mesonbuild#4767 states "All
cross compilation arguments come from the cross file". Except for: -D,
project(default_options: c_args...), executable( c_args, native:false),...
Then I looked for some relevant test code that would be in a less
natural language but necessarily in sync with the current
implementation. I couldn't really find any, so I wrote this (long)
sample. 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 not
hurt. Another cool thing would be to convert some of this to fully
automated tests and it's probably not too far from it, except for the
important question of: what particular combinations should be tested?
Can't test everything due to the number of locations and the
combinatorial explosion.
marc-h38
changed the title
This was referenced Jan 9, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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_argsdefinitions 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}_argsand 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_argstest code". That would be in a less natural language but never obsolete as github issues and PRs become. As I couldn't find anyc_argstest 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.