exporters - group by directories in prj root

[c1728p9]

Update exporter grouping code to group by directories in the root of the project rather than by the parent directory of each file. This reduces the number of groups and allows all mbed-os code to reside in its own folder.

[theotherjimmy]

This will not work on the online environment. Please use relpath(src, self.resources.file_basepath[src])

[c1728p9]

/morph export-build

[mbed-bot]

Result: SUCCESS

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

/morph export-build

Output

mbed Build Number: 76

All exports and builds passed!

[c1728p9]

@VeliMattiLahtela the cliapp job failed for this PR so I restarted it.

[bridadan]

@c1728p9 Do you mind showing a before and after of the project layout? So for https://github.com/ARMmbed/mbed-os-example-client would it look something like:

Before:

/source
/lwip
/targets
/TARGET_X
/TOOLCHAIN_X
(etc)

After:

/artmel-rf-driver
   - all files in all subdirectories flattened here
/esp8266-driver
   - all files in all subdirectories flattened here
/mbed-client
   - all files in all subdirectories flattened here
/mbed-os
   - all files in all subdirectories flattened here
(etc)

[c1728p9]

Here is what it looks like before (left) and after (right):

[bridadan]

@c1728p9 Are all of the mbed-os files flattened within the "mbed-os" directory in the "After" picture?

[c1728p9]

yeah

[0xc0170]

@c1728p9 Are all of the mbed-os files flattened within the "mbed-os" directory in the "After" picture?

If that's true, one folder will contain all mbed-os files without any structure? I don't like that. Having at least some tree there would be nice. As it is it's not ideal neither.

[c1728p9]

I agree, having a tree structure would be ideal. Correct me if I'm wrong but I was under the assumption that uvision only allowed one level of groups (directories). With this patch those groups match those of the root directory of the project. Prior to this patch each file was placed in a group with the name of its parent directory.

[bridadan]

Correct me if I'm wrong but I was under the assumption that uvision only allowed one level of groups (directories)

I believe that's correct yes.

[0xc0170]

I restarted jenkins CI. Once that green, should be ready to integrate

[sarahmarshy]

The non-nested groups is a limitation of uvision. It might be annoying now to edit mbed-os, as those files will be flattened, as mentioned above. However, the normal user probably wants to use uvision to modify their own source anyway.

[sarahmarshy]

Why the assert here? Wouldn't this trigger a runtime traceback if it were true?

[sarahmarshy]

Additionally, what is the check trying to accomplish? It is not comparing the length of the list.

[c1728p9]

Good catch. This is a mistake and should be removed or updated to be "len(path_list )".

[bridadan]

Thanks @c1728p9. Probably the easiest way to fix this is to just submit another PR, changing this assert to an exception that actually checks len(path_list). @sarahmarshy feel free to submit this if you know the proper way of handling the exception!

[sarahmarshy]

Is that correct behavior though? say src is C:\Project\mbed-os\src.cpp. Then relpath=mbed-os\src.cpp, then path_list = [mbed-os, src.cpp], which would be a list length >=1.

[c1728p9]

I created #3574 to fix this. This assert triggers in the case where the list is empty, as this is invalid and would cause an exception later anyway. This assert doesn't really matter though and I can remove it if you would like.