|
I think _javascript_ is the way to go. At the end, something like freemarker or embedded _javascript_ would fit the problem well.
My problem with Xtext and friends is that they're pretty heavy weight for this problem. And they still require creating plug-ins to hold the generated code.
Sent from my BlackBerry 10 smartphone on the Rogers network.
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
|
