I was wondering about that. I remember you working on it.
Where can we find documentation on how to use that?
From: cdt-dev-bounces@xxxxxxxxxxx [cdt-dev-bounces@xxxxxxxxxxx] on behalf of Pascal Rapicault [pascal@xxxxxxxxxxxx]
Sent: October 21, 2015 8:20 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] FW: New topic in forum C / C++ IDE (CDT), called Why can't it "just work"?, by Rob Lewis
FYI, since Mars, p2 has the ability to prompt the user to install native OS packages upon the installation of plug-ins.
It won't run the command for the user. It will simply display a dialog saying which commands to run.
HTH
On 15-10-21 04:03 PM, Marc-André Laperle wrote:
Hi!
I was thinking about this lately. I think an approach would be to install the toolchains (and other external tools) on demand and use the system's installation mechanism as much as possible. For example, if trying to debug and GDB is not there, it could execute
'apt-get install gdb' on Ubuntu (and other debian based distro) or wget MinGW's gdb, etc. There are many Eclipse plugins that need to interact with external tools and I don't expect that we can package all those things in update sites or products. What I mean
is that it would be very beneficial if there can be a somewhat common mechanism to detect and install missing external tools.
At it simplest it would do: Is this command on PATH ? no -> install known package that contains it (pkexec yum, apt-get or wget+unzip, xcode-select --install, etc)
Marc-Andre
Thanks gang, this is a very good discussion. I think there are concrete things we can do to help real beginners. And I don't think they're that hard. I am having great experience
with that on the Arduino C++ IDE. If you haven't seen the video I sent out earlier, please watch it. It's pretty close to the kind of experience I'm hoping we can bring to all C/C++ developers.
And that does bring up the point, we need more videos like this to help new users get started. They're really easy to make (I'm using Screencast-O-Matic which is cheap but pretty full featured) and are a fun way to learn.
We need to make sure we have first class support for the native compilers for our three major hosts. We could detect if the compilers are not installed and offering instructions on how to get them. Unfortunately Windows is by far the most popular host
and that's the hardest to get a toolchain for and we don't properly support Visual C++. In the end we probably need to produce a package for MinGW that can be easily installed via the Eclipse Marketplace (i.e., the old' Wascana).
I've mentioned before how we need to fix up our new project wizard to greatly simplify that workflow. It is the first experience our users have and it requires much more knowledge than they really need. Toolchains can come later for the experts who need
to worry about it.
We don't need managed make, but we do need to be able to automatically add and remove source files from the Makefiles. I am doing that with Arduino and with the new Qt, we are doing that with the .pro files. It's not that hard, especially if we're generating
the Makefile in the template and know the patterns.
And I think from there, we need to make sure the LaunchBar works for these projects. At the end of the day, people learning C++ just want to type in their code and hit run, just like they do in Visual Studio and Xcode.
I think that's a great start and I'll at least be working towards that for Neon because I do "pity" them and want them to be successful.
Doug.
Very interesting topic. We at HSR have seen students struggle with IDEs and of course also with CDT for years, actually more than ten. Fortunately, we’re at a university of applied science with students usually
have practical experience in IT and are used to stuff not working as they expected. I got the subjective impression that CDT improved significantly over the years. In the current C++ lecture and the corresponding exercise sessions we encounter very few obstacles
implied by CDT. Part of it might be that we have learned to prepare the students better for the IDE we force on them, as we have learned the reappearing problems pretty well. But eventually there are fewer pitfalls than before. In some cases we have added
functionality on top of CDT to lower the entry-level, for example we have a plug-in for configuring new C++ projects automatically for C++14 (setting compiler and indexer options).
For relieving the obstacles for setting up the whole environment (installing a compiler) we prepare a virtual machine which should provide everything needed in the exercises. Students working in their own environments
sometimes struggle with the compiler installation, especially getting a version compliant with the most recent C++ standard version that works correctly in most cases, was hard to find in the past. To overcome that CDT would need to be shipped with a native
compiler for the supplied platforms (Linux, MacOS and Windows). Or even provide its own means for compiling code for some platform-specific infrastructure. With our current thesis projects (topics template instance visualization, implementation of concepts
and C++14 constexpr evaluation – which actually requires an almost complete C++ interpreter) I can say that we are very far from that yet. Actually, we hardly able to cope with the pace of the C++ standard evolution with the CDT infrastructure, thus I don’t
think such an approach feasible. For this specific problem I’d rather suggest a bundle with a specific compiler and a good tutorial for setting up ones environment, “First steps with CDT”. Actually, I think this is a problem only students and programmers new
to C++ encounter. This obviously must not affect the proficient programmer negatively in any way. After all CDT is flexible regarding the underlying toolchain.
Another thing programmers/students proficient with JDT expect much more from the IDE while developing than CDT currently can provide. Most deficiencies in aspects like error reporting and development support
are inherited by the language. While I think it would fairly reasonable to implement better analysis and automated refactorings for “proper” C++ code, there is always at least one very weird case, enabled by the preprocessor, obsolete language features or
just because the standard says so, that also has to be considered when implementing such features. In a perfect world we could write code in CDT and receive all problems reported on the fly like the compiler would report them – best with a sensible problem
description and a resolution for fixing the problem. While Codan is a pretty good framework for this task, we don’t have all information required for complete error reporting in the index yet. Especially, template instantiation (afaik) stops at after the first
level. So far the information available is what is needed for navigation and refactoring. And that’s ok as a certain level of abstraction offers us better performance and responsiveness in the IDE, which I personally think is crucial. Here I actually see potential
for improvement, which was beneficial for newcomers and experts alike.
A C++ programmer eventually needs to know what happens behind the scenes. In CDT that point is encountered at the latest when working with multiple dependent projects. In my opinion even beginners should work
with an IDE as it can help you making progress much faster and I think that’s a crucial point when learning something. Of course the IDE must not be another hurdle on that path, adding another layer of problems and things that can go wrong. As I said in the
beginning of my wall of text, I think CDT currently is better than ever in that aspect. And with some good introductory tutorials most of such obstacles could be avoided. If they could be integrated into the IDE it was even better.
Regards
Thomas
Last time I checked, IDEs were for getting serious work done more quickly, not a my-first-code environment. First timers should be running g++ from the command line or a makefile as that's pretty much the first thing you need to learn to get anything going.
It's not that hard, either. gcc hello.c ; ./a.out
Just as I'd laugh at someone claiming to be a pro and using vim in a professional context, I'd strongly recommend that a beginner does exactly that with a plain editor, and learns the syntax through trial and error and gains a deep understanding of the basics.
Also, C++ is hardly a good language to cut your teeth on, it's more like taking a spin around the nurburgring in your corolla with learner plates. Throwing a kid in a google self driving car for a few laps won't help.
Anyway, my point was to try and get Doug to cheer up, CDT is f***ing awesome. All software has issues. All software always will have some issues. CDT was great when I first tried it, and it's 10 times better now than then. Software is complex, and takes
time, that's no less true when volunteers are writing it. Chin up, Doug! You're thoroughly appreciated in this corner, as are all of your colleagues around the globe.
Regards,
Fred.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|