|Deactivating Post Build processes [message #1198334]
||Wed, 20 November 2013 09:07
| Gregor Hendel
Registered: November 2013
Dear community, |
I am new to this forum. I am using CDT 8.1.2 for developing a C project. Simplified, the project root has a Makefile, a bin/- and a src/-subdirectory, and
a check/-subdirectory for testing and benchmarking the software.
Our group has a *large* library with benchmarking data, call it "/library" for now. In the project development so far, it was common sense (so far) to create a softlink
of /library into the check/-subdirectory to run automated benchmarks on the external data.
Now, every time I build my project code, everything works fine, but after compilation (program is already compiled and executable from console), there must be some background process scanning my entire project directory including the check/- and, in particular, the linked /library therein. This scan blocks consecutive processes like running or debugging from within eclipse for, say, 2-5 minutes after completing the actual build.
Removing the softlink relieves eclipse from every such occuring deadlock. Let's say, that this removal does not meet some project requirement.
I managed to exclude the check/-directory from both the CDT-indexer and from the project-explorer itself by setting appropriate filters, yet, this does not prevent the killer-post-build-scan from running into it.
I guess my egit extension runs into the same trouble when refreshing the repository.
My question is: What does eclipse do after the execution of my make-command terminated? Is there a way to deactivate this process or to add another filter?
Thank you for reading up to this point , I appreciate every hint you can give me on this.
For the time being, I resolved the problem the in the way above mentioned; by outsourcing the large library outside of my project-directory. Yet, there must
be a way to filter such file-system traps from within eclipse...
[Updated on: Mon, 02 December 2013 09:42]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.05364 seconds