Repository navigation
Add basic desktop linux checks - #31873
Conversation
| final List<ValidationMessage> messages = <ValidationMessage>[]; | ||
| /// Check for some version of GCC. | ||
| final ProcessResult gccResult = await processManager.run(const <String>[ | ||
| 'g++', |
There was a problem hiding this comment.
The choice of GCC vs clang is specific to the FDE example (and might be something we want to change before templatizing); it doesn't seem like we should have doctor check for things that aren't required by flutter_tool.
How about checking for make, since that's what the tooling actually expects at this point?
There was a problem hiding this comment.
The doctor could check make and then for both clang/gcc as a hint? Longer term, I would like to break out each doctor validation check to make it platform/template specific (see go/flutter-tool-extensions).
There was a problem hiding this comment.
I'm not familiar yet with the gradations of checks that the doctor support, but an error for not having make and a warning for not having gcc or clang definitely seems reasonable as a starting point. (Substituting whatever the right terminology is here for 'error' and 'warning')
|
|
||
| /// Check for the correct version of gtk. | ||
| final ProcessResult gtkResult = await processManager.run(const <String>[ | ||
| 'pkg-config', |
There was a problem hiding this comment.
We'd need to make sure pkg-config was present first. But as with GCC, I don't think we should actually be requiring that. The shell does have a runtime dependency on GTK, but that could be satisfied without pkg-config being present.
There was a problem hiding this comment.
These need not be required, but it could be a hint. Is there a better method to detect whether gtk is there at runtime?
There was a problem hiding this comment.
To be clear, when I say it's a runtime dependency I mean that end users of the built application need GTK; it's not a developer-specific thing. That's why I don't think doctor should check for it.
Is there a better method to detect whether gtk is there
It's Linux, so as always the answer seems to be "it depends on your distribution!"
Honestly I think that without a bunch of fallback logic and iteration with different distros we're likely to create a lot of false-positives (i.e., whatever we use to check of the presence of GTK is going to be missing more often than GTK), and that we're better off not doing this for now, and seeing if there's really a need for a GTK check in practice based on feedback.
stuartmorgan-g
left a comment
There was a problem hiding this comment.
Sorry, I totally forget about this PR :(
| final List<ValidationMessage> messages = <ValidationMessage>[]; | ||
| /// Check for some version of GCC. | ||
| final ProcessResult gccResult = await processManager.run(const <String>[ | ||
| 'g++', |
There was a problem hiding this comment.
I'm not familiar yet with the gradations of checks that the doctor support, but an error for not having make and a warning for not having gcc or clang definitely seems reasonable as a starting point. (Substituting whatever the right terminology is here for 'error' and 'warning')
|
|
||
| /// Check for the correct version of gtk. | ||
| final ProcessResult gtkResult = await processManager.run(const <String>[ | ||
| 'pkg-config', |
There was a problem hiding this comment.
To be clear, when I say it's a runtime dependency I mean that end users of the built application need GTK; it's not a developer-specific thing. That's why I don't think doctor should check for it.
Is there a better method to detect whether gtk is there
It's Linux, so as always the answer seems to be "it depends on your distribution!"
Honestly I think that without a bunch of fallback logic and iteration with different distros we're likely to create a lot of false-positives (i.e., whatever we use to check of the presence of GTK is going to be missing more often than GTK), and that we're better off not doing this for now, and seeing if there's really a need for a GTK check in practice based on feedback.
|
Closing this for now until I have some more time |
|
The template switched to Clang, which I intend to be a permanent change, so when this gets picked up again the initial version that covers everything needed for the simple example app should be:
|
|
This is back on my radar |
461c853 to
db53b22
Compare
|
Updated to check for clang++ greater than version 3.4 and make |
stuartmorgan-g
left a comment
There was a problem hiding this comment.
One more test note, but LGTM
|
cc @dnfield, do you know why this change would be failing the release_smoke_tests ? I don't know how to run it locally to debug, but this should have no effect on an Android build |
|
It looks like Gradle is failing to build in release mode with these changes. The command that's failing is |
|
Works fine locally, though I'm also on a mac |
|
Ah. I think this is the gradle emoji bug. Can you try replacing: with in cirrus.yml? |
|
Didn't work, can we submit on red for this case after I roll back the cirrus config? |
|
Looks like this is causing the following bot failures: |
This reverts commit f221ad1.
|
Not sure why CI didn't catch this - possibly some interaction between the PRs I landed today |
This reverts commit f221ad1.
Description
Adds doctor validation checks for gcc and gtk for linux desktop:
With -v
#31368