I think you lot are taking this too seriously. I must confess I
start most projects with "hello world with makefile" project, copy
and paste my own makefile in there and create a src directory. I'm
happy to provide this stock makefile if it'll help someone.
Anyway, it is not my IDE's place to install the rest of the DE. It
should not ask for sudo and so forth.
Maybe use the wiki pages instead?
Alec
Also the initial complaint of error messages, C++ has very few
keywords, there's not much to "lock onto" there and I agree with the
implementation, it shouldn't speculate on my exact error because
this is just speculation! I don't want to know what it probably is.
I want to know what actually failed.
Please keep the people who live and breath C++ (I do not claim to be
one of them!) - and not the learners at the forefront.
On 21/10/15 21:03, 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
|
