Not sure if it fits here, but I guess
you remember that there was once the Rhino project to have
scripting support in Eclipse.
The project dies some years ago, but it seems, someone want to
revive it as EASE
https://projects.eclipse.org/proposals/eclipse-advanced-scripting-environment-ease
Something on Eclipse, that I found always too bad was, that a
Non-Java Developer could never really extend Eclipse.
From my side, the entry curve to extending Eclipse was to high, as
you would have to learn Java, Eclipse, PDE and whatever first.
I'm also not sure, if EMF, Xtext, Xtend, Xpand, EMF Forms would be
of any help here?
Sure, that's more dependencies to CDT, but if it's useful, why
not?
Regards,
kessel
Am 23.04.2014 21:42, schrieb Doug Schaefer:
Excellent, gang, this is all great
input. As I expected we're all kind of coming at this from
different angles and it's quite a challenge to satisfy them all.
But we should give it a good try.
I like Elena's point that in the end, this is really all
about the template. What does the project look like after
we're done. The wizard is about tweaking the values and
behavior of the template generator. The differences between
the templates really shows we need to be a bit more generic
about that.
As an example, for Qt, you select an instance of qmake you
want to use to generate the makefiles. That instance implies a
toolchain, so why even present the toolchains pain? When you
want to add toolchains, you create new build configurations
and set the qmake you call for that config and generate to a
new build output directory. (BTW, this is what's driven me
here, trying to figure out how to do this properly).
Now, if you sum up all the potential templates, still end
up with a problem of scale. We need to figure a way to
categorize them. That'll be the tricky point and will need
some more thought.
And speaking of the template generator, as much as I love
the Symbian guys who contributed it, I find it a pretty
complicated. I'd love to find a way to be able to add
templates without writing Java code, especially now that we're
on Java 7 and have access to _javascript_. That could be another
activity we kick off from this.
But I definitely agree with the sentiment that we need to
consider all the use cases. You've presented a few so far. I'd
love to hear more examples.
Thanks!
Doug.
Personally I think the selection matrix
is too huge, so instead of trying to classify
everything, we can just have some
flexible way of extending wizard so each vendor
will use what is applicable for them. Generically
speaking everything is
a template, so user can pick one of the project
templates (in most generic sense) then move to the
next page of the wizard where
he can pick more specialized templates of this
type, and so on. For out of the box cdt/toolchain
(such as wascana) first level choices can be "New
Application", "New Library", "Existing Source", then
second level for library would be something like
"Static", "Shared", "Custom Makefile" etc.
But if we add tools for mobile development, first
level for example can become "Desktop" and "Mobile".
Most of the other choices have to be deducted
from template, for example when creating project
from existing source user have
to choose project location outside of workspace,
but when user creates "Desktop Application" ->
"Hello World C++" we assume it is managed AND it is
located in workspace, so we won't ask anything else.
Of cause there will be some "I will configure
everything myself" template for whatever we did not
consider.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|