Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re : Re: Adding a profile tool to a standard CDT toolchain

Yet I have to say that I really love Eclipse and all its capabilities and architecture...
For 25 years I have worked only with Visual Studio IDE. From 4.0 up to 2012 and C++. I couldn't believe there was a better IDE than Visual Studio or C++ language. Until I switched job and had to work with Eclipse and Java..! After 20 years with almost the same IDE I struggled a lot and couldn't find the IDE tools I wanted! It took me a year...Helped by 25 years younger developers than me to patiently bring me to a point were I was wowed by all the capabilities of Eclipse! I Learned a lot both at the coding and architecture level. And once I mastered Eclipse IDE I wouldn't want to go back with VS (At least for writing code not debugging)! I became a more proficient coder with Eclipse and really enjoyed the coding experience with it.
Since Microsoft released Visual 2012 I really hated what they did with the IDE. Thousand of developers are crying to Microsoft telling tell how they hate what they did to their beloved IDE.
So I hope that Eclipse CDT IDE will grow in architecture and coding stability. Its a great IDE. Thought that I believe much work is left to do for that they seems to be very close to bring the CDT to maturity.
Thanks guys for the great CDT plugin.
Keep the good work.
Le 03/07/13, Joseph Henry <Joseph.Henry@xxxxxxx> a écrit :

I feel your pain Guy!!


I too have struggled through the tooling mess and custom command lines just to get a few simple outputs.


It does seem like it should be much simpler to go from initial input to final output(s).


From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of guy.bonneau@xxxxxxxxxxxx
Sent: Tuesday, July 02, 2013 5:33 PM
To: cdt-dev@xxxxxxxxxxx
Subject: Re: [cdt-dev] Adding a profile tool to a standard CDT toolchain



After much digging in the CDT code I have progressed and I am now able to have the profiler tool kick-in with the appropriate inputs type and output target. However I am left with a feeling of something unfinished regarding how the output types (Primary or secondary) can be defined and are processed up to the command step building. For example I don't see how you can really produce many outputs (primary and secondaries) from a single tool since the command line pattern have only one ${OUTPUT} dedicated to the primary output.


I have nonetheless be able to bypass this problem by custom command line generation and using option definition. However I feel it shouldn't be that hard.


To have my profiler step builder created and executed I have had to solve an issue for which I have created a bug: The calculateOutput method of build description wrongly uses the tool outputs file extension attribute to create the resource outputs of any outputType associated to the tool. This prevent the build manager to resolve the appropriate build steps.




Back to the top