The new version of the xTIMEcomposer tool goes through all the source files creating dependencies before launching a debug session. This is very slow and annoying as the older version of the tool (V13)did not do this.
Is there a way to solve this?
Version 14 creates dependencies before debugging
-
gerrykurz
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
-
larry
- Respected Member
- Posts: 275
- Joined: Fri Mar 12, 2010 6:03 pm
Dependencies enable efficient incremental build, which can lead to faster times. You are right that sometimes it's not necessary, especially for smaller applications where a full build is quick enough.
Makefiles provided with XMOS tools don't have a no-incremental option, so the easiest solution would be writing a custom makefile.
Alternatively, removing dependency generation from the built-in makefiles might not be a big effort, starting in Makefile.plugin towards the bottom where xdep or gcc -MD are invoked to generate .d files.
Makefiles provided with XMOS tools don't have a no-incremental option, so the easiest solution would be writing a custom makefile.
Alternatively, removing dependency generation from the built-in makefiles might not be a big effort, starting in Makefile.plugin towards the bottom where xdep or gcc -MD are invoked to generate .d files.
-
gerrykurz
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
This is happening after a complete build.
The process is do a complete build of the project and then launch the debugger on the binary.
In V13, the tool simply checked to see if the build was up to date (it is) and then launched the debugger.
In V14, the tool does the same thing, checks to see if the build is up to date (it is) but then proceeds to create all the dependencies again before launching the debugger.
With a large project with many source files (AVB), this takes quite a bit of time.
The process is do a complete build of the project and then launch the debugger on the binary.
In V13, the tool simply checked to see if the build was up to date (it is) and then launched the debugger.
In V14, the tool does the same thing, checks to see if the build is up to date (it is) but then proceeds to create all the dependencies again before launching the debugger.
With a large project with many source files (AVB), this takes quite a bit of time.
-
myndideal
- Active Member
- Posts: 59
- Joined: Thu May 05, 2011 10:00 pm
- Location: Budapest
Hi,
I agree with gerrykurz, this behavior is not exactly what we want. (at least I have problem with it)
At point of launching the application, I never want to check if the binary is up-to-date. (possibly only when Iam tired :D )
Because I am the developer, and therefore I usually know what I am doing. If not, this is my fault. (So theres no need any automatic check, I would like to wait only for the downloading and restart processes to be finished as quick as possible!) As far as I understand, theres no way to download the xe without any other magic, it is only possible from command line... It would be nice, if we could choose exactly what we want. (build&launch, or just launch) Only in this case, I could be more happy with the automatic checking whatever feature...
By default, the editor is not automatically saves the edited files. This is a very dangerous behavior, after one day work everyone could prove. Because of this, completely pointless to do any building or checking on the sources at launch automaticaly.
Furthermore, there is something not so clear in the build script implementation. (14.0.3 build:17001) Which is run when we choose "Build project" (and possibly in launch case too).
I have all of my modules/libs listed in makefile, of course... But usually the "Build project" action does not exactly do the same thing. If the app project files have been modified, it is working good. When I am working on the dependant (referred) modules, best If I activate "Clean project" before Build, because it could give the previously compiled dep. binaries to linker otherwise, even if I belive it is compiled (because I pressed the "build")... I dont know the exact reason why, but something is around the included headers... Probably the depency list contains not all-of-the included files in a particular case. (or it use wrong file stamps for .h .d and .o comparison, trivially)
Is it checks only the makefile for the decision? Or is it use other infos too, like registered dependant projects which is added in the Eclipse "Project references" ?
These are together simply annoying things. So, there is a depency check algorithm which is not quite good. And We have to wait for it every launch. Not good at all...
Actually, I could work on an I7 w 16gigs ram, ssd, so I don't realy care about the compilation time a lot (even if my project already huge, it is quick, fast as lightning). But this depency check process somehow still slow, and wrong (as I described before).
I hope, I could help with this remarks.
I agree with gerrykurz, this behavior is not exactly what we want. (at least I have problem with it)
At point of launching the application, I never want to check if the binary is up-to-date. (possibly only when Iam tired :D )
Because I am the developer, and therefore I usually know what I am doing. If not, this is my fault. (So theres no need any automatic check, I would like to wait only for the downloading and restart processes to be finished as quick as possible!) As far as I understand, theres no way to download the xe without any other magic, it is only possible from command line... It would be nice, if we could choose exactly what we want. (build&launch, or just launch) Only in this case, I could be more happy with the automatic checking whatever feature...
By default, the editor is not automatically saves the edited files. This is a very dangerous behavior, after one day work everyone could prove. Because of this, completely pointless to do any building or checking on the sources at launch automaticaly.
Furthermore, there is something not so clear in the build script implementation. (14.0.3 build:17001) Which is run when we choose "Build project" (and possibly in launch case too).
I have all of my modules/libs listed in makefile, of course... But usually the "Build project" action does not exactly do the same thing. If the app project files have been modified, it is working good. When I am working on the dependant (referred) modules, best If I activate "Clean project" before Build, because it could give the previously compiled dep. binaries to linker otherwise, even if I belive it is compiled (because I pressed the "build")... I dont know the exact reason why, but something is around the included headers... Probably the depency list contains not all-of-the included files in a particular case. (or it use wrong file stamps for .h .d and .o comparison, trivially)
Is it checks only the makefile for the decision? Or is it use other infos too, like registered dependant projects which is added in the Eclipse "Project references" ?
These are together simply annoying things. So, there is a depency check algorithm which is not quite good. And We have to wait for it every launch. Not good at all...
Actually, I could work on an I7 w 16gigs ram, ssd, so I don't realy care about the compilation time a lot (even if my project already huge, it is quick, fast as lightning). But this depency check process somehow still slow, and wrong (as I described before).
I hope, I could help with this remarks.
-
gerrykurz
- XCore Addict
- Posts: 204
- Joined: Sun Jun 01, 2014 10:25 pm
I filed a support ticket about this and xmos says it will be fixed in the next release of the tools.
-
srinie
- XCore Addict
- Posts: 158
- Joined: Thu Mar 20, 2014 8:04 am
Hi,
If in case you 've not yet tried it, the command line version of the tools may serve as interim workaround.
If in case you 've not yet tried it, the command line version of the tools may serve as interim workaround.