Exporters - projectfiles removal and progendef name broken again?

[0xc0170]

Description

• Type: Question

Issues:

1. progendef name reverted

   This fix was reverted: theotherjimmy@9b89fc3 here theotherjimmy@f4a686f .
   There's no explanation in the commit message. As I shared the link this is a caveat in pypi (references in the commit message and in the original issue). Is this issue back on master?

2. projectfiles removal

   This commit removes - 7ee6213

   No reason given, contains again multiple logical changes. (debug info should be a separate commit).

   Why were projectfiles removed? Now if a user use one example for 2 boards, the project files get overwritten, and I believe we don't clean all garbage created by the IDE. The root gets lot of files that are unknown to a user.

@theotherjimmy @sarahmarshy

Please split commits logically, and create smaller patches that won't hide details like this from a reviewer or user. Thanks

[sarahmarshy]

If a user wants to have multiple configurations, they can rename the file. We were accommodating a lot of logic just to maintain the relativity of paths in some cases, but not in others (zip exporting). This is more reliable and works across IDEs and make. For example, Eclipse project file in the root makes it possible to open the directory as a workspace. Varied configurations is mainly a feature supported for mbed developers. It isn't the average use case, as most people are accustomed to developing for a specific platform.

[sarahmarshy]

Garbage unknown to the user is par for the course with IDEs, and relocating it to another directory doesn't necessarily change that.

[0xc0170]

If a user wants to have multiple configurations, they can rename the file

If it was one file, ok, but there are multiple files created, it pollutes a user workspace.

Garbage unknown to the user is par for the course with IDEs, and relocating it to another directory doesn't necessarily change that.

Lot of SDK produce project files in separate directories for reasons above.

If it was in the different export specific folder, you can easily clean - remove the project files or specific project and regenerate. Do we have that functionality now? Or we need to use git clean?
Plus a user know that all that junk is in this specific location, no pollution. This is a use case mainly for IDE like uvision or others that produce lot of internal files.

Thanks for providing more inputs for this. All that info you provided should have been part of the commit messages.

This is just my 5 cents, I often use multiple configurations, targets for testing. Previously it was simple, now I find it difficult. I easily manage this with a git, to get tracked files, and clean the rest. Is this what we expect from a user?

I just tried to use clean to see if we provide clean command for t his new directory structure (do we really try to clean .git folder?):

 mbed export -c --i uvision
Traceback (most recent call last):
  File "C:\2\mbed-os-example-blinky\mbed-os\tools\project.py", line 227, in <module>
    main()
  File "C:\2\mbed-os-example-blinky\mbed-os\tools\project.py", line 223, in main
    zip_proj=zip_proj, options=options.opts)
  File "C:\2\mbed-os-example-blinky\mbed-os\tools\project.py", line 87, in export
    macros=macros, libraries_paths=lib, zip_proj=zip_name, options=options)
  File "C:\2\mbed-os-example-blinky\mbed-os\tools\project_api.py", line 181, in export_project
    rmtree(export_path)
  File "C:\Python27\lib\shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Python27\lib\shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Python27\lib\shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "C:\Python27\lib\shutil.py", line 252, in rmtree
    onerror(os.remove, fullname, sys.exc_info())
  File "C:\Python27\lib\shutil.py", line 250, in rmtree
    os.remove(fullname)
WindowsError: [Error 5] Access is denied: '.\\.git\\objects\\09\\6996e82299ae954b0a724605e3aac3d8e312f3'

I'll create a new issue for mbed export -c, this is just a highlight that if we produce it within root, we should provide clean method to clean it all !

[theotherjimmy]

I easily manage this with a git, to get tracked files, and clean the rest. Is this what we expect from a user?

We could have the clean flag do exactly that.

I'll create a new issue for mbed export -c,

Thanks! I'm responding in that thread for the clean issue.

[theotherjimmy]

progendef name reverted

Sorry about that. It was certainly not intended (which is why the commit message does not reflect the change) and my have been a messed up git merge/rebase

[0xc0170]

Sorry about that. It was certainly not intended (which is why the commit message does not reflect the change) and my have been a messed up git merge/rebase

Please send PR to revert that commit, thanks

[theotherjimmy]

Please send PR to revert that commit, thanks

Coming soon.

[ciarmcom]

ARM Internal Ref: IOTMORF-482

[theotherjimmy]

I think this is resolved now.