Add GNU ARM Eclipse exporter #3561
Conversation
|
This is the preliminary version of the exporter, not yet functional. The following problems were identified:
It looks like I'm missing something, or the current configuration might have some problems. For reference, I issued the following commands: The full console log is: Please advise. |
| except AttributeError: | ||
| # TODO filter out projects with toolchain core not supported, | ||
| # instead of raising an exception. | ||
| raise Exception('Target core {0} not supported.'.format(core)) |
There was a problem hiding this comment.
Can we use NotSupportedException here? it's in tools/utils.py
sorry, but I don't know where to get these flags from. :-( can you provide a link to another exporter that does this? |
That's very strange. I can't think of anything off the top of my head that could be causing that.
That should not be a problem, because it's sub folders should not be excluded.
This implies that my previous assumption is false.
This is something that I can immediately help with. You are missing the
I was typing this response as this came up. Glad we're on the same page. |
|
The format is: {
"c": [ "flags"],
"cxx": [ "flags"],
"asm": [ "flags"],
"ld": ["flags"]
} |
|
The second commit fixed the NotSupportedException issue. |
|
I was a bit busy fixing another GNU ARM Eclipse issue, but now I'm back.
I'm afraid we have a big misunderstanding here. simplifying things, the Eclipse CDT managed build, require a list of source folders, a list of include folders, a list of symbols and some compile options for the used tools. when starting the build, the source folders are scanned for .c, .cpp, .cxx, .cc, .S files, and all files identified are added to the generated make files, then the make is invoked. if the but this is just annoying. the real problem is that many of the files, even if they look like legal source files (.c, .cpp, etc) should not be part of the build (the best example are test files). so, in order to perform a build in Eclipse, I need to know exactly which are the folders with source files, keeping the entire
right, I ignored the I checked it and, as it is prepared by the Exporters class, is of little use, since it includes again the symbols, which I already process separately; I had to overwrite it with a version that does not add the symbols. however, integrating this with GNU ARM Eclipse is a bit tedious, since my plug-ins have quite an elaborate configuration mechanism, with most of the options having separate GUI entries, so options need to be identified in your list and specific settings need to be passed in the CDT configuration.
I added this and now however, although legal, using FYI, a preliminary build of In my opinion, the list of includes and defines is excessively long. FYI, such a long line (>9300 bytes), on Windows, which has a 8K limit on command line length, would not be allowed. next I'll work on the procedures to properly pass options. please advice on how to proceed with the |
|
|
I constantly get this message:
if |
The initial {{uid}} was evaluated once. To force an evaluation for
each call, use an object property {{u.id}}.
Okay, here is how I would construct these things:
Where did you get a Debug folder from? I don't think there is one generated by the tools, or checked into the repo.
It's not required, it is optional. I have been considering a way to remove that optional dependency. It may come in another PR. |
The use of
Yep. You are welcome to push all of the symbols into another header file and |
the Debug folder is created by CDT. usually CDT projects have two build configurations, Debug & Release. each build uses one of these folders to create the binary files and everything else necessary during the build. so, in this case, the question is why the exporter enumerates these folders? do you have a better strategy to get the list of object files I need to add to the link step? |
The tools iterate through all of the files and directories present in a project, skipping:
No You could work around this in several ways:
I'm sure there are more, but off of the top of my head, these are it |
unfortunately the user can create any number of configurations, and name them as he wishes, I have no control over these names. the problem occurs if export is run again, after performing Eclipse builds, which create these folders. it looks like, for the moment, we have to keep |
@ilg-ul I'm sorry, but that is not an option. I suggest an alternative: by default do something that works with both tool sets. If a user modifies the configuration provided by the exporter they are 'on their own' in a sense. The sense is that they might not be able to use |
|
Additionally, they probably will not run export again. If they use the Eclipse exporter like a user (rather than a developer exporting many times), then they will use Eclipse to manage/add files after the initial project creation. |
do not count on this. user inventiveness is limitless. |
Agreed. But our ability to support arbitrary inventiveness is limited. |
unfortunately the entries in this set cannot be used directly, because CDT recursively searches the folders, and there are many parent folders and subfolders, with parent folders also containing folders that must not be included in the build. the logic to compute exclusions requires some complicated tree processing. :-( |
Yeah. That's why we have been using a "specify the files exactly" strategy in the exporters. I'm sorry, but we are unlikely to reorganize the directory structure to accommodate the invariant that directories included also guarantee that all of their sub-directories are also included. |
hmmm... this raises another question: assuming I manage to write the tree exclusion logic and I identify the folders to build, can you guarantee that all source files in those folders really should be included in the build? all .c/.cpp/.cxx/.S files? because Eclipse, unless there are explicit exclusions, will try to compile all those files. if you have the list of source files, perhaps safer would be to process these entries, not the folders. |
This seems so much easier. It's |
|
One thing that worries me here is proliferation of eclipse exports, what's the difference between |
did you manage to export and build the
I'll try to add a section to the exporters page, but let's first make it work properly. |
that doesn't make any sense, if it works like that it's a bug and should be changed -> your 'gnuarmeclipse' changes should replace the @theotherjimmy correct me if i'm wrong |
|
thank you all! now we need to do something to update the documentation. any suggestions where to start? what is the 5.4 ETA? how much time do we have for the documentation? |
|
We have 2-3 weeks, I think. The documentation is in the handbook. https://github.com/ARMmbed/Handbook @AnotherButler, could you help out with getting the documentation for GNU ARM Eclipse in the right place? |
|
how can we regenerate the |
|
Not sure how to generate |
|
The related existing page is https://github.com/ARMmbed/Handbook/blob/5.3/docs/dev_tools/third_party.md. We could add to this or create a new page if there's enough information to fill one. |
|
I'd rather just delete |
+1 what do we do with the exporters that do not generate functional projects? from my past experience, these exporters only manage to frustrate users. my initial proposal was to temporarily disable them until fixed. |
|
#3797 Is the PR to remove it BTW. |
|
@ilg-ul I was thinking of moving some of the code you have to the exporter base classes. In particular, I was thinking of moving the compute directory exclude logic up. I may move a few more up. I'll mention you on the PR so that you can review. |
sure, no problem. perhaps you can also think of a better solution to process all profiles. |
Working on this now. I'm going to change the |
|
Is 5.4 out? I noticed that the GNU ARM Eclipse exporter is mentioned by the documentation, but I could not find it in the web compiler exporters list. |
|
@ilg-ul Could you guide me on how to use the exporter, and how should I import the files in eclipse? Here is what i have done:
FYI I have an i7 machine and if I use Thanks again for your time, |
|
@theotherjimmy, I tried to reproduce Carlo's problem and I encountered this: any idea what went wrong? |
|
@CarloMara, could you check your bullet no. 3? what do you mean by 'Why did you rm mbed-os? ' step no. 4 seems ok, but it looks like something wrong happened with mbed, since I also had problems, even worse than your. |
|
Dear lord..... On the very first post you rm'd the whole mbed-os folder with:
I didn't execute that, because I couldn't find a plausible motivation for doing so. I will try now to redo what I have done, to see if I get your errors. Cheers, |
|
yep, same error |
ah, right, but that message had a completely different purpose, to replace the stable version of mbed-os downloaded with the blink project with a development version cloned from git. the current documentation for the exporter is available from: https://docs.mbed.com/docs/mbed-os-handbook/en/latest/dev_tools/third_party/ (this location is not very fortunate, it needs some more work) |
|
So, yhea my guess was right. That wasn't needed. When I will figure out how to do this, I will add some pics to the GNUARM section of the docs, so it's even easier for beginners. Still, now there is a new bug somewhere. Go figure (; Carlo |
|
Since the patch has been merged on master, I tried again to export the project using mbed cli luckily without encountering any of problems that @ilg-ul did find. Even with this small "road block" fixed my main issue remains, I can't compile the project from eclipse.
On a side note, I'm planning to use a Nucleo F303K8 board from ST, but from what I have seen the standard for test commands is K64F, so I'm sticking with it until I can get this working. Thanks again 4 your time, |
where do you search for the result? check for a Debug folder, possibly after a refresh.
what simulator?
the BUILD folder is not used by Eclipse. |
|
I can't find any debug folder, nor in eclipse nor via command line. Here it's what I see in the folder after running build: As you can see, there is no Debug folder.... Regarding the simulator, I was referring to QEMU which, from my understanding, runs when I click on the play button. This kinda makes sense, because when the play button is clicked eclipse complains about not finding the binaries... I was guessing that the build folder was used exclusively by mbed, so thanks for confirming that. On a side note, how can we increase the verbosity of the compiler output in an mbed project? Thanks again, |
do a clean and a new build, then copy the first and last lines of the console. eclipse is quite verbose, displays all compiler/linker commands. if you do not see those lines, you have a problem.
please check what configurations you have in your project, and which one is active when you hit the hammer button. if I remember right, the exporter create 3 configurations, one for each mbed profile. building each configuration should contribute a folder with the same name in the project root.
no, it is not that easy, you need to create debug configurations, for qemu as for any other debugger. I suggest you follow the GNU ARM Eclipse blinky tutorial 'by the book', but only after you install all GNU ARM Eclipse components, exactly as documented. after you complete this tutorial, perhaps you'll understand how Eclipse works, and what to expect from the mbed exporter. |
|
Ok, I checked and I can see only the @ilg-ul What's the best way to proceed? Should I reinstall everything? Cheers, |
what problem? if you asked Eclipse to build the if I remember right mbed has three profiles, so you got three Eclipse configurations in your project, you can build them one by one, or build them all, and you'll finally get three folders with the results of the build. what did you expect to happen? if you have specific problems, please use separate issues, this thread is already too long and is closed. |
|
I'm sorry I wasn't clear. If I go into the project configuration the only build config I see it's Thanks again, EDIT: |
|
please open separate issues, and explain what you expected, what actually happened, and the procedure to reproduce the problem. |
NOTICE: the GNU ARM Eclipse exporter went public with mbed version 5.4.
Preliminary documentation is available from:
https://docs.mbed.com/docs/mbed-os-handbook/en/latest/dev_tools/third_party/
For further problems, please open new issues.