Fix issue with unrecognized uvision file types

[sarahmarshy]

Description

Fixes #3010. Does not add them to accepted file types, but instead does not fail. Header files will show up in the project tree as children of the files that depend on them.

Status

READY

@nuket @sg- @theotherjimmy

[sarahmarshy]

/morph export-build

[mbed-bot]

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph export-build

[0xc0170]

Is this desirable? Not showing header files? I am aware they are not required for project to be built. but I find them vital during the development within IDE. I would keep them in.

As your commit message says, they are visible as dependency, but this is true just for uvision. A unified view would be to have them in project or not at all.

[sarahmarshy]

This is just for uvision, so they will still show up.

[0xc0170]

This is just for uvision, so they will still show up.

It should be consistent across tools, thus I would vote to keep header files in IDE. It's different, to know which files includes the header I want to open versus find the header in the workspace view. If we remove header files, should be done for all tools. But then again as it was pointed out in one issue, if in eclipse for instance the header file is not present, their highlighter or whatever they call it does not know what macros are defined and can't highlight properly the code that is "active".

To fix that unsupported issue reported, we add the most common extensions. I can think of having .h, `.hpp``. We could argue about linker file as well, that it is usually defined in the project itself, but good to have for viewing in the workspace view.

I would propose to extend to support header files with .hpp, possibly .hh as well?

Update: our tools recognize .h and .hpp, our tools should also:

        elif ext == '.h' or ext == '.hpp':
            resources.headers.append(file_path)

[0xc0170]

Removing .h files - -1, but that refactoring and renaming +1

[sarahmarshy]

It won't remove the .h files. It actually ends up looking nicer, because they show up as an expandable list under the file that depends on them. Go ahead and give export to uvision a shot. You'll still see them and be able to edit them in your project!

[0xc0170]

This is my workspace, show include dependencies is enabled :

I have installed 5.17 currently. I'll need to update to the latest 5.21 or above soon, so can try that one. There are also empty folders.

My view still standing, I would keep headers in the tree. This list of dependencies can be used anyway.

[sg-]

@sarahmarshy will plan to merge #3010 but want changes for validation and not exposing the traceback. Will you rebase and keep the .h and .hpp for consistency across IDEs once merged. Sorry for flip flopping on this. Didnt realize other IDEs didn't use nested headers in the navigation tree

[sarahmarshy]

@sg- I made the necessary changes now, but I will wait for #3010

[sg-]

/morph export-build

[mbed-bot]

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph export-build

Output

mbed Build Number: 19

Exporter Build failed!

[theotherjimmy]

Those failures are fixed by this PR #3243

[theotherjimmy]

Failures unrelated. LGTM

[sg-]

Lets get that in first then.

[0xc0170]

/morph export-build

[bridadan]

Apologies for the not updated GitHub status, the CI server's power cord got nudged today and messed up the statuses. If you follow the details link though you can see everything passed! So LGTM