Home » Language IDEs » C / C++ IDE (CDT) » Future directions
| Future directions [message #74144] |
Fri, 27 June 2003 04:12  |
Eclipse User |
|
|
|
Originally posted by: fdboer.baan.com
Hello folks,
This week I got a first glimpse of the CDT and my first impression was quite
positive. After a better look however, I was a bit disapointed. Allthough
the CDT seems to work and you can actually do development, the current
implementation seems to be no more than a C/C++ editor/build facilitator,
not a real project management provider. In other words, it won't replace
Microsoft Visual Studio functionality yet ... (or I must be missing
something)
Despite, still praise to the developers because they seem to have build a
nice foundation. And sure, Rome wasn't build in one day either.
I couldn't find any documentation about future directions like what
functionality to be added and (aproximately) when.
Features I would like to see:
- hide the makefile, fine to use it under water but I want it hidden from
the project
(no need to make ant build scripts when using the JDT)
- allow references to external shared libraries (or DLL's on WIN32)
(like external JAR references in the JDT)
- provide different types of projects (eg. executable; shared library; etc.)
Any ideas, pointers or references about what can be expected?
Just my 2 cents, regards,
Feico de Boer
|
|
|
| Re: Future directions [message #74164 is a reply to message #74144] |
Fri, 27 June 2003 10:18  |
| Eclipse User |
|
|
|
Originally posted by: mikhailk.qnx.com
The CDT 1.2 draft plan was posted a couple of days ago. To see the plan,
just go to the CDT main web page and follow the link from "development
plan/schedules".
"Feico de Boer" <fdboer@baan.com> wrote in message
news:bdgu5e$4fo$1@rogue.oti.com...
> Hello folks,
>
> This week I got a first glimpse of the CDT and my first impression was
quite
> positive. After a better look however, I was a bit disapointed. Allthough
> the CDT seems to work and you can actually do development, the current
> implementation seems to be no more than a C/C++ editor/build facilitator,
> not a real project management provider. In other words, it won't replace
> Microsoft Visual Studio functionality yet ... (or I must be missing
> something)
>
> Despite, still praise to the developers because they seem to have build a
> nice foundation. And sure, Rome wasn't build in one day either.
>
> I couldn't find any documentation about future directions like what
> functionality to be added and (aproximately) when.
>
> Features I would like to see:
> - hide the makefile, fine to use it under water but I want it hidden from
> the project
> (no need to make ant build scripts when using the JDT)
> - allow references to external shared libraries (or DLL's on WIN32)
> (like external JAR references in the JDT)
> - provide different types of projects (eg. executable; shared library;
etc.)
>
> Any ideas, pointers or references about what can be expected?
>
> Just my 2 cents, regards,
>
> Feico de Boer
>
>
|
|
|
| Re: Future directions [message #74182 is a reply to message #74144] |
Sat, 28 June 2003 19:57 |
| Eclipse User |
|
|
|
Feico de Boer wrote:
> Hello folks,
>
> This week I got a first glimpse of the CDT and my first impression was quite
> positive. After a better look however, I was a bit disapointed. Allthough
> the CDT seems to work and you can actually do development, the current
> implementation seems to be no more than a C/C++ editor/build facilitator,
> not a real project management provider. In other words, it won't replace
> Microsoft Visual Studio functionality yet ... (or I must be missing
> something)
>
> Despite, still praise to the developers because they seem to have build a
> nice foundation. And sure, Rome wasn't build in one day either.
>
> I couldn't find any documentation about future directions like what
> functionality to be added and (aproximately) when.
>
> Features I would like to see:
> - hide the makefile, fine to use it under water but I want it hidden from
> the project
> (no need to make ant build scripts when using the JDT)
Well, that opinion just gave me a clue now, why a lot of so called
developers are not familiar with their tools they use.
And thats what pisses me off, cause if something doesn't work, they
don't know how to fix it by hand.
And as you probably don't know, there are a lot more dialects on
different toolchains, MSVC isn't the only one!
Also, Makefiles give you a lot more control over the project to build,
and I won't like to have that hidden from me!
> - allow references to external shared libraries (or DLL's on WIN32)
> (like external JAR references in the JDT)
Well, that's what you could do in the Makefile, i.e. by adding it to the
LDFLAGS using gcc/g++.
> - provide different types of projects (eg. executable; shared library; etc.)
Done in Makefiles too.
> Any ideas, pointers or references about what can be expected?
Read the CDT News Page and you'll find the plan.
> Just my 2 cents, regards,
IMHO, you can keep your money.
|
|
|
| Re: Future directions [message #74199 is a reply to message #74182] |
Sun, 29 June 2003 07:00 |
| Eclipse User |
|
|
|
Originally posted by: uwe.kaos-group.de
Hi,
> Also, Makefiles give you a lot more control over the project to build,
> and I won't like to have that hidden from me!
True enough, but in large projects handling makefiles is an very time
consuming issue. However, CDT should build a foundation and should
concentrate on the C/C++ parsing, navigation, editing stuff and should
provide a simple build solution which the Makefiles fulfills absolutly
fine. I'm quite sure that ISV's will show up with "hiding the makefile
stuff" plugins.
>> - provide different types of projects (eg. executable; shared library;
>> etc.)
>
> Done in Makefiles too.
And done in CDT too. If I'm not wrong, the Managed Build project type offers
such things. You can select to build a executable or a library during
project creation ... and it can be extended with more types within
org.eclipse.cdt.ui/plugin.xml. However, for the moment I would stick to the
makefiles.
Best regards,
--
Uwe
mailto: uwe@kaos-group.de
|
|
|
| Re: Future directions [message #74216 is a reply to message #74199] |
Sun, 29 June 2003 07:56 |
| Eclipse User |
|
|
|
I may have sounded a bit to mature in my post, but I still have the same
opinion.
gkar wrote:
> Hi,
>
>
>>Also, Makefiles give you a lot more control over the project to build,
>>and I won't like to have that hidden from me!
>
>
> True enough, but in large projects handling makefiles is an very time
> consuming issue. However, CDT should build a foundation and should
> concentrate on the C/C++ parsing, navigation, editing stuff and should
> provide a simple build solution which the Makefiles fulfills absolutly
> fine. I'm quite sure that ISV's will show up with "hiding the makefile
> stuff" plugins.
Right, Makefiles can be tideous in large projects, but then, I'm pretty
sure, you guys will find suitable solutions to handle such. But that's
not CDT's problem to include that, cause that wouldn't be working. CDT
is just right about providing a base foundation for external tool builders.
I.e. how should CDT handle tools which provide Versioning _and_
Configuration Management? That's something CDT could provide its base
features, but the adaptation can only be done by some tool vendor. There
are just too much tools around.
>>>- provide different types of projects (eg. executable; shared library;
>>>etc.)
>>
>>Done in Makefiles too.
>
>
> And done in CDT too. If I'm not wrong, the Managed Build project type offers
> such things. You can select to build a executable or a library during
> project creation ... and it can be extended with more types within
> org.eclipse.cdt.ui/plugin.xml. However, for the moment I would stick to the
> makefiles.
Sure, despite the fact it's actually not more than a starting point yet.
|
|
|
| Re: Future directions [message #74307 is a reply to message #74182] |
Mon, 30 June 2003 05:01 |
| Eclipse User |
|
|
|
Originally posted by: fdboer.baan.com
"kesselhaus" <kesselhaus@gmx.net> wrote in message
news:bdla22$2tu$1@rogue.oti.com...
> Feico de Boer wrote:
> > Hello folks,
> >
> > This week I got a first glimpse of the CDT and my first impression was
quite
> > positive. After a better look however, I was a bit disapointed.
Allthough
> > the CDT seems to work and you can actually do development, the current
> > implementation seems to be no more than a C/C++ editor/build
facilitator,
> > not a real project management provider. In other words, it won't replace
> > Microsoft Visual Studio functionality yet ... (or I must be missing
> > something)
> >
> > Despite, still praise to the developers because they seem to have build
a
> > nice foundation. And sure, Rome wasn't build in one day either.
> >
> > I couldn't find any documentation about future directions like what
> > functionality to be added and (aproximately) when.
> >
> > Features I would like to see:
> > - hide the makefile, fine to use it under water but I want it hidden
from
> > the project
> > (no need to make ant build scripts when using the JDT)
>
> Well, that opinion just gave me a clue now, why a lot of so called
> developers are not familiar with their tools they use.
> And thats what pisses me off, cause if something doesn't work, they
> don't know how to fix it by hand.
You've set the tone but I just couldn't resist to write a response. What
pisses me off are those so called experts that think that assume that anyone
that uses (the comfort of) an IDE is a nono without tools knowledge. Having
done porting activities in a professional environment for over 3 years, I
had my share of makefiles and Imakefiles, configure miseries and different
tools. I just like the comfort of the IDE but I know my way around on *nix
and Microsoft Windows. Actually, maybe to make things up, my favorite editor
is still (g)vim (and no, I'm not that hardcore that I use emacs).
> And as you probably don't know, there are a lot more dialects on
> different toolchains, MSVC isn't the only one!
I'm compiling open source code since I first got access to the Internet,
that's aproximately 10 years ago by now. You know, that was the (good old)
time that a 9k6 modem connection was still sufficient for a proper newsfeed.
Yes, I'm very well aware that there is live besides Microsoft. Despite their
name, I almost don't dare to admit, I feel they do good things to (ouch,
flame war warning, where is the fire brigade ?). Two things Microsoft is
good in, marketing and making technology accessible.
> Also, Makefiles give you a lot more control over the project to build,
> and I won't like to have that hidden from me!
Well, I would like to see the basics hidden, I would hate to see loss of
control. However, in my opinion there is no problem in combining the two.
This is in perticular true if the basic control element for building is the
makefile, either explicitely visible or implicit.
> > - allow references to external shared libraries (or DLL's on WIN32)
> > (like external JAR references in the JDT)
>
> Well, that's what you could do in the Makefile, i.e. by adding it to the
> LDFLAGS using gcc/g++.
Preferably using ed ... ;-)
> Read the CDT News Page and you'll find the plan.
Well, sorry. I found it and again sorry that I must it the first time.
> > Just my 2 cents, regards,
>
> IMHO, you can keep your money.
You're not going to get it. ;-)
Kind regards,
Feico
|
|
|
| Re: Future directions [message #74326 is a reply to message #74307] |
Mon, 30 June 2003 06:55 |
| Eclipse User |
|
|
|
Feico de Boer wrote:
>
> "kesselhaus" <kesselhaus@gmx.net> wrote in message
> news:bdla22$2tu$1@rogue.oti.com...
>> Feico de Boer wrote:
>> > Hello folks,
>> >
>> > This week I got a first glimpse of the CDT and my first impression was
> quite
>> > positive. After a better look however, I was a bit disapointed.
> Allthough
>> > the CDT seems to work and you can actually do development, the current
>> > implementation seems to be no more than a C/C++ editor/build
> facilitator,
>> > not a real project management provider. In other words, it won't
>> > replace Microsoft Visual Studio functionality yet ... (or I must be
>> > missing something)
>> >
>> > Despite, still praise to the developers because they seem to have build
> a
>> > nice foundation. And sure, Rome wasn't build in one day either.
>> >
>> > I couldn't find any documentation about future directions like what
>> > functionality to be added and (aproximately) when.
>> >
>> > Features I would like to see:
>> > - hide the makefile, fine to use it under water but I want it hidden
> from
>> > the project
>> > (no need to make ant build scripts when using the JDT)
>>
>> Well, that opinion just gave me a clue now, why a lot of so called
>> developers are not familiar with their tools they use.
>> And thats what pisses me off, cause if something doesn't work, they
>> don't know how to fix it by hand.
>
> You've set the tone but I just couldn't resist to write a response. What
> pisses me off are those so called experts that think that assume that
> anyone that uses (the comfort of) an IDE is a nono without tools
> knowledge. Having done porting activities in a professional environment
> for over 3 years, I had my share of makefiles and Imakefiles, configure
> miseries and different tools. I just like the comfort of the IDE but I
> know my way around on *nix and Microsoft Windows. Actually, maybe to make
> things up, my favorite editor is still (g)vim (and no, I'm not that
> hardcore that I use emacs).
Yeah, I know, I can't keep my fingers under control sometimes. ;)
I don't consider myself an expert in all the things. But I get to learn the
tools I use, and yes, I had been using MSVC too. The comfort of the IDE is
sometimes helpful, sometimes it just keeps you from work by searching an
option in the dialogs. I don't consider an Makefile comfortable but I can
get around with it until some management is being developed. If you would
also please take a look on the development ressources available to the CDT
team?
Somewhere, their have to be priorities, and I think, CDT does a good job for
now, even though it's not comparable to JDT but it will come.
But as I said, there are just such a lot of tools outside, that the CDT team
can just provide the basic framework for extension. The Managed Build is a
starting point yet, but it just came out as an proposal. They postponed it
for rather more needful stuff. Actually, TimeStorm was the first Eclipse
Clone I've seen with Build Management, and that had been back in Nov./Dec.
2002. The CDT started the Build Management now, but it got not far from
plannings and some rudimentary implementation.
>> And as you probably don't know, there are a lot more dialects on
>> different toolchains, MSVC isn't the only one!
>
> I'm compiling open source code since I first got access to the Internet,
> that's aproximately 10 years ago by now. You know, that was the (good old)
> time that a 9k6 modem connection was still sufficient for a proper
> newsfeed. Yes, I'm very well aware that there is live besides Microsoft.
> Despite their name, I almost don't dare to admit, I feel they do good
> things to (ouch, flame war warning, where is the fire brigade ?). Two
> things Microsoft is good in, marketing and making technology accessible.
Did I already excuse me?
>> Also, Makefiles give you a lot more control over the project to build,
>> and I won't like to have that hidden from me!
>
> Well, I would like to see the basics hidden, I would hate to see loss of
> control. However, in my opinion there is no problem in combining the two.
> This is in perticular true if the basic control element for building is
> the makefile, either explicitely visible or implicit.
As I said above, and as you probably read some scheduling and development
proposals from CDT you probably know too, they just happen to start the
Build Management.
>> > - allow references to external shared libraries (or DLL's on WIN32)
>> > (like external JAR references in the JDT)
>>
>> Well, that's what you could do in the Makefile, i.e. by adding it to the
>> LDFLAGS using gcc/g++.
>
> Preferably using ed ... ;-)
Well, why not use the vi, as we both don't like emacs. ;)
>> Read the CDT News Page and you'll find the plan.
>
> Well, sorry. I found it and again sorry that I must it the first time.
>
>> > Just my 2 cents, regards,
>>
>> IMHO, you can keep your money.
>
> You're not going to get it. ;-)
You sure? ;)
> Kind regards,
>
> Feico
Regards,
Henning
PS: Hope we got our points straight. ;)
|
|
|
| Re: Future directions [message #74524 is a reply to message #74144] |
Tue, 01 July 2003 09:14 |
| Eclipse User |
|
|
|
Originally posted by: eddielee.tropicsoft.com
"Feico de Boer" <fdboer@baan.com> wrote in message
news:bdgu5e$4fo$1@rogue.oti.com...
> Hello folks,
>
> This week I got a first glimpse of the CDT and my first impression was
quite
> positive. After a better look however, I was a bit disapointed. Allthough
> the CDT seems to work and you can actually do development, the current
> implementation seems to be no more than a C/C++ editor/build facilitator,
> not a real project management provider. In other words, it won't replace
> Microsoft Visual Studio functionality yet ... (or I must be missing
> something)
>
> Despite, still praise to the developers because they seem to have build a
> nice foundation. And sure, Rome wasn't build in one day either.
>
> I couldn't find any documentation about future directions like what
> functionality to be added and (aproximately) when.
>
> Features I would like to see:
> - hide the makefile, fine to use it under water but I want it hidden from
> the project
> (no need to make ant build scripts when using the JDT)
> - allow references to external shared libraries (or DLL's on WIN32)
> (like external JAR references in the JDT)
> - provide different types of projects (eg. executable; shared library;
etc.)
>
> Any ideas, pointers or references about what can be expected?
>
> Just my 2 cents, regards,
I heartily agree with your 2 cents worth. Don't pay any attention to the
fanatics who want all development stopped at the level of make files,
command lines, and primitive editors.
Future directions I would like to see:
1) GUI frameworks ( ala wxWindows, Qt, KDE, Gnome etc. ) and visual tools
2) Project managers ( ala VC++, C++ Builder, CodeWarrior )
3) Web application frameworks ( ala cgi, fastcgi )
4) Visual component frameworks ( ala Borland's VCL )
5) Editors ( ala CodeWright, Emacs, whatever your favorite is )
6) Visual debuggers
7) Case tools
8) Profilers
When these appear, over time, CDT will have achieved some of its goals. I
don't view the use of Make files as anything but a decent beginning in
functionality.
Also, although Eclipse platform is itself free, I don't see any reason why
3rd party plug-ins shouldn't charge money for the adaptations of their
products to the Eclipse environment. This would provide an incentive for
adding plug-ins to Eclipse for developers who already have any of the above
and can see profits adapting their software to the Eclipse platform.
|
|
|
| Re: Future directions [message #74578 is a reply to message #74524] |
Tue, 01 July 2003 14:59 |
| Eclipse User |
|
|
|
Edward Diener wrote:
> I heartily agree with your 2 cents worth. Don't pay any attention to the
> fanatics who want all development stopped at the level of make files,
> command lines, and primitive editors.
Hmm, I don't consider myself fanatic, but I seem to look like someone. ;)
What's wrong on the possibility to keep your hands dirty on Makefiles? I
don't want to have it disappear by the means like VC++, where you
actually have to export an Makefile to compile by hand.
I.e. how would you integrate options for developing for Embedded
Systems, when Compiler/Linker Flags are used that are not common to
developers doing GUI Apps?
You have to adapt the Dialogs to a vast amount of Toolchains.
Or how would you adapt to the autoconf, automake etc.
But if someone has some nice open solutions to convince me, I wouldn't mind.
> Future directions I would like to see:
>
> 1) GUI frameworks ( ala wxWindows, Qt, KDE, Gnome etc. ) and visual tools
> 2) Project managers ( ala VC++, C++ Builder, CodeWarrior )
> 3) Web application frameworks ( ala cgi, fastcgi )
> 4) Visual component frameworks ( ala Borland's VCL )
> 5) Editors ( ala CodeWright, Emacs, whatever your favorite is )
What do you mean by that? Like emulation of the behaviour of them?
There are already some community plugins on that issue, like EE2E or the
viPlugin.
> 6) Visual debuggers
As your preferred debugger has some communication interface, it should
be adaptable like the GDB, if you meant this.
> 7) Case tools
We probably should ask some of the CASE Tool Providers like
Omondo-EclipseUML, to provide an C++ adaptation. I agree, that most CASE
Tools available are just Java-centric.
> 8) Profilers
>
> When these appear, over time, CDT will have achieved some of its goals. I
> don't view the use of Make files as anything but a decent beginning in
> functionality.
But I don't want to have it hidden at all. Maybe the way it's done now,
with the Managed Build vs. Std. Make Project, we both get our wishes.
I think about something like:
Select Project Type:
* Plain C/C++
* wxWindows
* MFC
* X11
* GNOME/GTK/Glade
* Qt/KDE
* etc.
Select Managed Builds:
* Not Managed
* GNU C/C++ Cygwin
* GNU C/C++ MinGW
* GNU C/C++ Linux
* VC++
* DDK
* BCB
* etc.
But then, someone has to bring up something to configure such things,
and I personally would like to have something easily
editable/extendable, not written all in Java Modules/Plugins.
> Also, although Eclipse platform is itself free, I don't see any reason why
> 3rd party plug-ins shouldn't charge money for the adaptations of their
> products to the Eclipse environment. This would provide an incentive for
> adding plug-ins to Eclipse for developers who already have any of the above
> and can see profits adapting their software to the Eclipse platform.
I agree, even though a lot of Eclipse users probably can't afford tools
like Rational Rose (thats just an example for price ranges!). Therefore,
some limited editions would be nice.
|
|
|
| Re: Future directions [message #74595 is a reply to message #74578] |
Tue, 01 July 2003 18:30 |
| Eclipse User |
|
|
|
Originally posted by: eddielee.tropicsoft.com
kesselhaus wrote:
> Edward Diener wrote:
>
>> I heartily agree with your 2 cents worth. Don't pay any attention to
>> the fanatics who want all development stopped at the level of make
>> files, command lines, and primitive editors.
>
> Hmm, I don't consider myself fanatic, but I seem to look like
> someone. ;)
>
> What's wrong on the possibility to keep your hands dirty on
> Makefiles? I don't want to have it disappear by the means like VC++,
> where you
> actually have to export an Makefile to compile by hand.
I don't mind having Makefiles available in whatever form they exist for
editing at the lowest level for those who want them. But IDE's which create
projects and let one set compiler/linker options visually should exist
without the programmer having to edit Makefiles by hand,
>
> I.e. how would you integrate options for developing for Embedded
> Systems, when Compiler/Linker Flags are used that are not common to
> developers doing GUI Apps?
>
> You have to adapt the Dialogs to a vast amount of Toolchains.
> Or how would you adapt to the autoconf, automake etc.
>
> But if someone has some nice open solutions to convince me, I
> wouldn't mind.
>
>
>> Future directions I would like to see:
>>
>> 1) GUI frameworks ( ala wxWindows, Qt, KDE, Gnome etc. ) and visual
>> tools 2) Project managers ( ala VC++, C++ Builder, CodeWarrior )
>> 3) Web application frameworks ( ala cgi, fastcgi )
>> 4) Visual component frameworks ( ala Borland's VCL )
>> 5) Editors ( ala CodeWright, Emacs, whatever your favorite is )
>
> What do you mean by that? Like emulation of the behaviour of them?
> There are already some community plugins on that issue, like EE2E or
> the viPlugin.
I don't know what EE2E is and I imagine viPlugin is for Vi. I would like to
see editors which are sold to plug-in to the Eclipse platform. Of course
this is up to the vendor and what they want to charge.
>
>> 6) Visual debuggers
>
> As your preferred debugger has some communication interface, it should
> be adaptable like the GDB, if you meant this.
I don't see why some visual debugger which understands the debug output of a
given plug-in compiler couldn't be a plug-in itself. Obviously a plug-in
compiler could come with its own visual debugger.
>
>> 7) Case tools
>
> We probably should ask some of the CASE Tool Providers like
> Omondo-EclipseUML, to provide an C++ adaptation. I agree, that most
> CASE Tools available are just Java-centric.
A good OOP case tool often is able to adapt itself to more than one OOP
language. I see no reason why good C++ case tools might not exist as
plug-ins to Eclipse.
>
>> 8) Profilers
>>
>> When these appear, over time, CDT will have achieved some of its
>> goals. I don't view the use of Make files as anything but a decent
>> beginning in functionality.
>
> But I don't want to have it hidden at all. Maybe the way it's done
> now,
> with the Managed Build vs. Std. Make Project, we both get our wishes.
"It hidden" meaning what ?
As I said, for those using the command-line or editing make files or
whatever, let them keep using those tools if they like. I would like to see
a visual IDE which makes it easy to develop applications for different
platforms of different types using various visual tools which make C++
development easier. We already have many examples of this with specific
compilers/implementations so I see no reason why Eclipse couldn't adopt some
of those ideas and even convince those who have done their own proprietary
implementations to adapt a version for Eclipse if they felt there was profit
to be made doing so.
>
> I think about something like:
> Select Project Type:
> * Plain C/C++
> * wxWindows
> * MFC
> * X11
> * GNOME/GTK/Glade
> * Qt/KDE
> * etc.
>
Good.
> Select Managed Builds:
> * Not Managed
> * GNU C/C++ Cygwin
> * GNU C/C++ MinGW
> * GNU C/C++ Linux
> * VC++
> * DDK
> * BCB
> * etc.
Much harder. I think the implementation would have their own system for
building and once one chooses what type of project to build and specifies
the files for that project, the build system would create the final
output(s) automatically. Of course between the selecting of the tool and
project type and the building of the final product, there may be many other
plug-ins helping the programmer to create the product, many of them visual
and probably a number of them automatically generating code from programmer
input. Needless to say the programmer must write some code normally but good
visual tools can reduce the redundancy of writing wrappers by a huge amount,
and of course libraries and application frameworks can reduce this further.
>
> But then, someone has to bring up something to configure such things,
> and I personally would like to have something easily
> editable/extendable, not written all in Java Modules/Plugins.
Most of the visual systems with which I have worked, including my editor,
allows me to extend functionality through OOP and class resue and
inheritance. I see no problem doing this whether it is in C++ ( preferred by
me ) or Java, or whatever, if the extensibility is designed well.
>
>> Also, although Eclipse platform is itself free, I don't see any
>> reason why 3rd party plug-ins shouldn't charge money for the
>> adaptations of their products to the Eclipse environment. This would
>> provide an incentive for adding plug-ins to Eclipse for developers
>> who already have any of the above and can see profits adapting their
>> software to the Eclipse platform.
>
> I agree, even though a lot of Eclipse users probably can't afford
> tools
> like Rational Rose (thats just an example for price ranges!).
> Therefore, some limited editions would be nice.
Rational Rose is outrageously priced so is an extreme example of a plug-in
addition to Eclipse. I can see companies charging anything from $50 or so
shareware prices to hundreds of dollars and, if the functionality is worth
it, people will buy. What I have found, although the freeware community may
deny it in their zeal for everything-free software, is that freeware
implementations in general are not nearly as good as vendor implementations
which cost money. But arguing about this is not the point, only that Eclipse
should encourage vendors wanting to make a profit to provide implementations
of their product as Eclipse plug-ins at whatever price they deem sufficient.
The market, and Eclipse's technical excellence and popularity, will
determine whether those vendors succeed or not. Of course if others want to
supply free plug-ins, so much the better.
|
|
|
| Re: Future directions [message #74631 is a reply to message #74595] |
Wed, 02 July 2003 06:05 |
| Eclipse User |
|
|
|
Edward Diener wrote:
> kesselhaus wrote:
>> Edward Diener wrote:
>>
>>> I heartily agree with your 2 cents worth. Don't pay any attention to
>>> the fanatics who want all development stopped at the level of make
>>> files, command lines, and primitive editors.
>>
>> Hmm, I don't consider myself fanatic, but I seem to look like
>> someone. ;)
>>
>> What's wrong on the possibility to keep your hands dirty on
>> Makefiles? I don't want to have it disappear by the means like VC++,
>> where you
>> actually have to export an Makefile to compile by hand.
>
> I don't mind having Makefiles available in whatever form they exist for
> editing at the lowest level for those who want them. But IDE's which
> create projects and let one set compiler/linker options visually should
> exist without the programmer having to edit Makefiles by hand,
I think my main conecerns about such build systems are situations like this
little example: Up to Version 8.x SuSE (Linux) had been developing tools
for setting up Linux. They did it in a way that was "proprietary" (I hate
that word, isn't there another one?). After each cycle of setting something
up visually, you will be sitting in your seat and see Yast (the setup tool)
go through all its own config files, even though you did not change anything
on them but one. The other problem had been, you couldn't just do a quick
change in the real config files, since yast will be overriding it the next
time.
Though, what I mean is, I know I want to change option XYZ and I know I
want/could to do it at point A in the Makefile. Fast way, open Makefile and
change at A option XYZ. Long way, open the Dialogs, search through the
options, try to set the option. But, this way, handmade changes could be
overwritten.
>>
>> I.e. how would you integrate options for developing for Embedded
>> Systems, when Compiler/Linker Flags are used that are not common to
>> developers doing GUI Apps?
>>
>>> 5) Editors ( ala CodeWright, Emacs, whatever your favorite is )
>>
>> What do you mean by that? Like emulation of the behaviour of them?
>> There are already some community plugins on that issue, like EE2E or
>> the viPlugin.
>
> I don't know what EE2E is and I imagine viPlugin is for Vi. I would like
> to see editors which are sold to plug-in to the Eclipse platform. Of
> course this is up to the vendor and what they want to charge.
EE2E is a plugin, that emulates the Emacs behaviour on top of the opened
Perspective, same does viPlugin except it simulates VI behaviour.
The question had been, what should these editors provide? Simulate their
originating editor and in what way?
>>
>>> 6) Visual debuggers
>>
>> As your preferred debugger has some communication interface, it should
>> be adaptable like the GDB, if you meant this.
>
> I don't see why some visual debugger which understands the debug output of
> a given plug-in compiler couldn't be a plug-in itself. Obviously a plug-in
> compiler could come with its own visual debugger.
I still don't got that. The GDB used right now, has an Communication
Interface, so you can remotely control GDB to debug something.
I'm not sure if lets say the VC++ Debugger has some kind of this interface.
So, what you could do is right now, start the Debugger as External Tool.
Is that what you meant? Using given Visual Debuggers?
>>
>>> 7) Case tools
>>
>> We probably should ask some of the CASE Tool Providers like
>> Omondo-EclipseUML, to provide an C++ adaptation. I agree, that most
>> CASE Tools available are just Java-centric.
>
> A good OOP case tool often is able to adapt itself to more than one OOP
> language. I see no reason why good C++ case tools might not exist as
> plug-ins to Eclipse.
Sure, they are able to adapt to any language they have an Generator for, but
right now, I just see Java Generators here and there. Also, support for
Patterns and the like is right now more centered on Java.
>>
>>> 8) Profilers
>>>
>>> When these appear, over time, CDT will have achieved some of its
>>> goals. I don't view the use of Make files as anything but a decent
>>> beginning in functionality.
>>
>> But I don't want to have it hidden at all. Maybe the way it's done
>> now,
>> with the Managed Build vs. Std. Make Project, we both get our wishes.
>
> "It hidden" meaning what ?
>
> As I said, for those using the command-line or editing make files or
> whatever, let them keep using those tools if they like. I would like to
> see a visual IDE which makes it easy to develop applications for different
> platforms of different types using various visual tools which make C++
> development easier. We already have many examples of this with specific
> compilers/implementations so I see no reason why Eclipse couldn't adopt
> some of those ideas and even convince those who have done their own
> proprietary implementations to adapt a version for Eclipse if they felt
> there was profit to be made doing so.
>
>>
>> I think about something like:
>> Select Project Type:
>> * Plain C/C++
>> * wxWindows
>> * MFC
>> * X11
>> * GNOME/GTK/Glade
>> * Qt/KDE
>> * etc.
>>
>
> Good.
>
>> Select Managed Builds:
>> * Not Managed
>> * GNU C/C++ Cygwin
>> * GNU C/C++ MinGW
>> * GNU C/C++ Linux
>> * VC++
>> * DDK
>> * BCB
>> * etc.
>
> Much harder. I think the implementation would have their own system for
> building and once one chooses what type of project to build and specifies
> the files for that project, the build system would create the final
> output(s) automatically. Of course between the selecting of the tool and
> project type and the building of the final product, there may be many
> other plug-ins helping the programmer to create the product, many of them
> visual and probably a number of them automatically generating code from
> programmer input. Needless to say the programmer must write some code
> normally but good visual tools can reduce the redundancy of writing
> wrappers by a huge amount, and of course libraries and application
> frameworks can reduce this further.
Well, by selecting the managed build I meant to select the toolchain used,
since them need probably more specialization in the generation of the files
for the build process. The problem is, i.e. if you select an
Qt/KDE-Project, you will be in the need of tools like uic and moc, which
are now not really part of the Managed Build Configuration, as t/qmake
aren't. That's something I meant when I said: How would you integrate such
things? There are just to much tools out there to suit them all. And that
was also the question to ask, why they want to integrate the tools by the
means of Java (ICTool etc.) instead of having a general launcher and
integrating it more the way of writing maybe some XML files to configure
them. If you are writing Java classes around all the Tools, that wouldn't
be good to extend and/or adapt. What, if the Programmer of the Java-Class
forgot to include some options? You write the Toolclass again?
Take the Qt Example:
* I want to make Qt Progs so I could use tmake (Qt2.x) or qmake (>3.x) for
building the Makefiles, or just use a preconfigured Makefile.
* The Toolchain you use depends on your system
- Windows: VC++, Cygwin, MinGW, (Borland?)
- Unix/Linux: GNU C/C++, Intel, whatever...
So how would you integrate now the uic and moc?
>>
>> But then, someone has to bring up something to configure such things,
>> and I personally would like to have something easily
>> editable/extendable, not written all in Java Modules/Plugins.
>
> Most of the visual systems with which I have worked, including my editor,
> allows me to extend functionality through OOP and class resue and
> inheritance. I see no problem doing this whether it is in C++ ( preferred
> by me ) or Java, or whatever, if the extensibility is designed well.
>
>>
>>> Also, although Eclipse platform is itself free, I don't see any
>>> reason why 3rd party plug-ins shouldn't charge money for the
>>> adaptations of their products to the Eclipse environment. This would
>>> provide an incentive for adding plug-ins to Eclipse for developers
>>> who already have any of the above and can see profits adapting their
>>> software to the Eclipse platform.
>>
>> I agree, even though a lot of Eclipse users probably can't afford
>> tools
>> like Rational Rose (thats just an example for price ranges!).
>> Therefore, some limited editions would be nice.
>
> Rational Rose is outrageously priced so is an extreme example of a plug-in
> addition to Eclipse. I can see companies charging anything from $50 or so
> shareware prices to hundreds of dollars and, if the functionality is worth
Yes, it was an extreme example, but think of developers not able to buy your
nice plugins, cause one would end up buying several plugins and spending
500...1000$? I mean, right now I could not afford it. (I do not cry, but I
see my own financial situation critical these times)
Thats what I meant, maybe some kind of limited community edition, if this
works, if you can't split then,... that's life.
> it, people will buy. What I have found, although the freeware community
> may deny it in their zeal for everything-free software, is that freeware
> implementations in general are not nearly as good as vendor
> implementations which cost money. But arguing about this is not the point,
> only that Eclipse should encourage vendors wanting to make a profit to
> provide implementations of their product as Eclipse plug-ins at whatever
> price they deem sufficient. The market, and Eclipse's technical excellence
> and popularity, will determine whether those vendors succeed or not. Of
> course if others want to supply free plug-ins, so much the better.
I agree. I sure would be happy to have plugins I need and if they would be
free. I'm not someone fanatic in having all for nothing. Developers and
companies need their life paid. But I wouldn't say, that there are such a
lot of crap is in the free side. It might not be that sophisticated as some
commercial plugin, and the guy writing it might not think far enough
because he doesn't see the usage as a company would see, but there are some
ideas coming from the community, companies could maybe adapt and extend.
|
|
|
| Re: Future directions [message #74861 is a reply to message #74144] |
Thu, 03 July 2003 14:30 |
| Eclipse User |
|
|
|
Make is the first integration point because so many C++ projects (non
Microsoft ones anyway) currently use it. We have talked about supporting an
internal build once we have the managed-make solution for 1.2 under control.
No promises on a timeline for this work however ...
JohnC
"Feico de Boer" <fdboer@baan.com> wrote in message
news:bdgu5e$4fo$1@rogue.oti.com...
> Hello folks,
>
> This week I got a first glimpse of the CDT and my first impression was
quite
> positive. After a better look however, I was a bit disapointed. Allthough
> the CDT seems to work and you can actually do development, the current
> implementation seems to be no more than a C/C++ editor/build facilitator,
> not a real project management provider. In other words, it won't replace
> Microsoft Visual Studio functionality yet ... (or I must be missing
> something)
>
> Despite, still praise to the developers because they seem to have build a
> nice foundation. And sure, Rome wasn't build in one day either.
>
> I couldn't find any documentation about future directions like what
> functionality to be added and (aproximately) when.
>
> Features I would like to see:
> - hide the makefile, fine to use it under water but I want it hidden from
> the project
> (no need to make ant build scripts when using the JDT)
> - allow references to external shared libraries (or DLL's on WIN32)
> (like external JAR references in the JDT)
> - provide different types of projects (eg. executable; shared library;
etc.)
>
> Any ideas, pointers or references about what can be expected?
>
> Just my 2 cents, regards,
>
> Feico de Boer
>
>
|
|
|
| Re: Future directions [message #74999 is a reply to message #74861] |
Thu, 03 July 2003 20:17 |
| Eclipse User |
|
|
|
Originally posted by: eddielee.tropicsoft.com
John Camelon wrote:
> Make is the first integration point because so many C++ projects (non
> Microsoft ones anyway)
Microsoft uses Make also under the covers. You can always generate a Make
file from any VC++ project of 5.0 through 7.1 .
> currently use it. We have talked about
> supporting an internal build once we have the managed-make solution
> for 1.2 under control. No promises on a timeline for this work
> however ...
An internal Make would be nice as long as the visual tools allowed one to
set the compiler/link options graphically. But that is just the tip of the
iceberg for whar cdt could encompass. I envision a visual RAD tool for C++
in which implementors could offer their plug-ins to speed development for an
OS , the Web, client-server, web services etc.
>
> JohnC
>
> "Feico de Boer" <fdboer@baan.com> wrote in message
> news:bdgu5e$4fo$1@rogue.oti.com...
>> Hello folks,
>>
>> This week I got a first glimpse of the CDT and my first impression
>> was quite positive. After a better look however, I was a bit
>> disapointed. Allthough the CDT seems to work and you can actually do
>> development, the current implementation seems to be no more than a
>> C/C++ editor/build facilitator, not a real project management
>> provider. In other words, it won't replace Microsoft Visual Studio
>> functionality yet ... (or I must be missing something)
>>
>> Despite, still praise to the developers because they seem to have
>> build a nice foundation. And sure, Rome wasn't build in one day
>> either.
>>
>> I couldn't find any documentation about future directions like what
>> functionality to be added and (aproximately) when.
>>
>> Features I would like to see:
>> - hide the makefile, fine to use it under water but I want it hidden
>> from the project
>> (no need to make ant build scripts when using the JDT)
>> - allow references to external shared libraries (or DLL's on WIN32)
>> (like external JAR references in the JDT)
>> - provide different types of projects (eg. executable; shared
>> library; etc.)
>>
>> Any ideas, pointers or references about what can be expected?
>>
>> Just my 2 cents, regards,
>>
>> Feico de Boer
|
|
|
| Re: Future directions [message #75070 is a reply to message #74999] |
Sat, 05 July 2003 19:20 |
| Eclipse User |
|
|
|
I didn't think that they would use nmake under the covers though ... there's
disadvantages to integrating lots of different tools in this way, as tool
error parser have to sift through Make noise as well ... a tool does not
have to use Make internally in order to export a build representation in
Make format.
Then again, I don't work for M$OFT so I don't know ...
"Edward Diener" <eddielee@tropicsoft.com> wrote in message
news:be2h7d$on8$1@rogue.oti.com...
> John Camelon wrote:
> > Make is the first integration point because so many C++ projects (non
> > Microsoft ones anyway)
>
> Microsoft uses Make also under the covers. You can always generate a Make
> file from any VC++ project of 5.0 through 7.1 .
>
> > currently use it. We have talked about
> > supporting an internal build once we have the managed-make solution
> > for 1.2 under control. No promises on a timeline for this work
> > however ...
>
> An internal Make would be nice as long as the visual tools allowed one to
> set the compiler/link options graphically. But that is just the tip of the
> iceberg for whar cdt could encompass. I envision a visual RAD tool for C++
> in which implementors could offer their plug-ins to speed development for
an
> OS , the Web, client-server, web services etc.
>
> >
> > JohnC
> >
> > "Feico de Boer" <fdboer@baan.com> wrote in message
> > news:bdgu5e$4fo$1@rogue.oti.com...
> >> Hello folks,
> >>
> >> This week I got a first glimpse of the CDT and my first impression
> >> was quite positive. After a better look however, I was a bit
> >> disapointed. Allthough the CDT seems to work and you can actually do
> >> development, the current implementation seems to be no more than a
> >> C/C++ editor/build facilitator, not a real project management
> >> provider. In other words, it won't replace Microsoft Visual Studio
> >> functionality yet ... (or I must be missing something)
> >>
> >> Despite, still praise to the developers because they seem to have
> >> build a nice foundation. And sure, Rome wasn't build in one day
> >> either.
> >>
> >> I couldn't find any documentation about future directions like what
> >> functionality to be added and (aproximately) when.
> >>
> >> Features I would like to see:
> >> - hide the makefile, fine to use it under water but I want it hidden
> >> from the project
> >> (no need to make ant build scripts when using the JDT)
> >> - allow references to external shared libraries (or DLL's on WIN32)
> >> (like external JAR references in the JDT)
> >> - provide different types of projects (eg. executable; shared
> >> library; etc.)
> >>
> >> Any ideas, pointers or references about what can be expected?
> >>
> >> Just my 2 cents, regards,
> >>
> >> Feico de Boer
>
>
|
|
|
| Re: Future directions [message #75083 is a reply to message #75070] |
Sat, 05 July 2003 21:51 |
| Eclipse User |
|
|
|
Originally posted by: eddielee.tropicsoft.com
John Camelon wrote:
> I didn't think that they would use nmake under the covers though ...
> there's disadvantages to integrating lots of different tools in this
> way, as tool error parser have to sift through Make noise as well ...
> a tool does not have to use Make internally in order to export a
> build representation in Make format.
>
> Then again, I don't work for M$OFT so I don't know ...
My remark was wrong because I don't know what the actual code does. I should
only have said that you can always have the IDE generate a Make file for you
to use which will work just like the Make that one chooses visually when
using the IDE. You can also see, as you choose compiler and linker options,
the actual compiler and linker commands, which will be passed to the
internal Make process.
The argument being made was that MS doesn't use a Make file while nearly
every other IDE does. I just wanted to emphasize that the VC++ IDE for a
long time has been able to generate a Make file which is exactly equivalent
to whatever they do internally to Make a project from within the IDE.
MS has always promoted the idea that a programmer can use Make files to
build a VC++ project if one wishes rather than use the IDE. Borland does the
same. I like an IDE which allows users to use Make files but also offers to
hide the nitty, gritty details of Make file generation behind visual tools
which take care of the job to be done. I hope CDT moves in that direction. I
think it would be poor not to do so considering the advanced IDEs which now
exist for C++ programming.
>
> "Edward Diener" <eddielee@tropicsoft.com> wrote in message
> news:be2h7d$on8$1@rogue.oti.com...
>> John Camelon wrote:
>>> Make is the first integration point because so many C++ projects
>>> (non Microsoft ones anyway)
>>
>> Microsoft uses Make also under the covers. You can always generate a
>> Make file from any VC++ project of 5.0 through 7.1 .
>>
>>> currently use it. We have talked about
>>> supporting an internal build once we have the managed-make solution
>>> for 1.2 under control. No promises on a timeline for this work
>>> however ...
>>
>> An internal Make would be nice as long as the visual tools allowed
>> one to set the compiler/link options graphically. But that is just
>> the tip of the iceberg for whar cdt could encompass. I envision a
>> visual RAD tool for C++ in which implementors could offer their
>> plug-ins to speed development for an OS , the Web, client-server,
>> web services etc.
>>
>>>
>>> JohnC
>>>
>>> "Feico de Boer" <fdboer@baan.com> wrote in message
>>> news:bdgu5e$4fo$1@rogue.oti.com...
>>>> Hello folks,
>>>>
>>>> This week I got a first glimpse of the CDT and my first impression
>>>> was quite positive. After a better look however, I was a bit
>>>> disapointed. Allthough the CDT seems to work and you can actually
>>>> do development, the current implementation seems to be no more
>>>> than a C/C++ editor/build facilitator, not a real project
>>>> management provider. In other words, it won't replace Microsoft
>>>> Visual Studio functionality yet ... (or I must be missing
>>>> something)
>>>>
>>>> Despite, still praise to the developers because they seem to have
>>>> build a nice foundation. And sure, Rome wasn't build in one day
>>>> either.
>>>>
>>>> I couldn't find any documentation about future directions like what
>>>> functionality to be added and (aproximately) when.
>>>>
>>>> Features I would like to see:
>>>> - hide the makefile, fine to use it under water but I want it
>>>> hidden from the project
>>>> (no need to make ant build scripts when using the JDT)
>>>> - allow references to external shared libraries (or DLL's on WIN32)
>>>> (like external JAR references in the JDT)
>>>> - provide different types of projects (eg. executable; shared
>>>> library; etc.)
>>>>
>>>> Any ideas, pointers or references about what can be expected?
>>>>
>>>> Just my 2 cents, regards,
>>>>
>>>> Feico de Boer
|
|
|
| Re: Future directions [message #75100 is a reply to message #75083] |
Sun, 06 July 2003 09:52 |
| Eclipse User |
|
|
|
Edward Diener wrote:
> John Camelon wrote:
>
>>I didn't think that they would use nmake under the covers though ...
>>there's disadvantages to integrating lots of different tools in this
>>way, as tool error parser have to sift through Make noise as well ...
>>a tool does not have to use Make internally in order to export a
>>build representation in Make format.
>>
>>Then again, I don't work for M$OFT so I don't know ...
>
>
> My remark was wrong because I don't know what the actual code does. I should
> only have said that you can always have the IDE generate a Make file for you
> to use which will work just like the Make that one chooses visually when
> using the IDE. You can also see, as you choose compiler and linker options,
> the actual compiler and linker commands, which will be passed to the
> internal Make process.
I never said, MSVC doesn't do Makefiles, I just said, that this Dialect
of Microsoft Makefiles is different to i.e. the Dialect of GNU Make.
And that is IMHO the problem, that there are just that much tools
around. There are even developers around, which don't use a Makfile but
some Shell-Scripts (may it be Windows or Unix).
> The argument being made was that MS doesn't use a Make file while nearly
> every other IDE does. I just wanted to emphasize that the VC++ IDE for a
> long time has been able to generate a Make file which is exactly equivalent
> to whatever they do internally to Make a project from within the IDE.
Yes, but I think, you still see your very own position. There are not
only application developers. And as you dig deeper in programming other
stuff, IMHO you get at restrictions of using Dialogs to setup things.
If you really want to hide things behind the scene, you either end up
doing dialogs for this kind and that kind, or you might get stuck on not
being able to setup options, cause the option isn't just there.
Though, thats what my concern is about, hiding the Makefile from the
User. It's the same like using GUI-Builders, they can do a lot of work
for you, but usually, they are just dumb, creating code, that shouldn't
be changed by hand (cause then the GUI-Builder might not be able to read
back in), and even worse sometimes create just redundant code.
The matter of hiding things is just a getting the usual way done quick,
but if you want to dig deeper, you are forced to not use visual tools.
> MS has always promoted the idea that a programmer can use Make files to
> build a VC++ project if one wishes rather than use the IDE. Borland does the
> same. I like an IDE which allows users to use Make files but also offers to
> hide the nitty, gritty details of Make file generation behind visual tools
> which take care of the job to be done. I hope CDT moves in that direction. I
> think it would be poor not to do so considering the advanced IDEs which now
> exist for C++ programming.
The question probably is, defining what a "advanced IDE" is, what it can
do and what not. Because, if you leave the usual way, you can't come
back to the visual way. And that is in all IDE's I've seen so far.
And that's why I have the point, developers should understand their
tools and how to use them. I'm not fanatic about the Makefiles, but if I
get to the point where visual tools don't work, I know where to look for
getting it done by hand. That is my main concern in this discussion, and
it doesn't have to do with fanatic hackers or such.
H. Riedel
|
|
|
| Re: Future directions [message #75117 is a reply to message #74861] |
Sun, 06 July 2003 12:07 |
| Eclipse User |
|
|
|
John,
Is it possible to define an api to build systems? You could
define a set of build events and the build plugins would listen to the
events and respond.
plugins could be written for make, ant, Visual Studio, ..
We have a very large system, and are migrating toward
ant with custom build rules.
The time based dependencies break down on very large systems.
It is very useful to incorperate symantic change information
to the build rules.
Any thoughts on going to an build api with a defined set of build
events?
Thanks
Mike
John Camelon wrote:
> Make is the first integration point because so many C++ projects (non
> Microsoft ones anyway) currently use it. We have talked about supporting an
> internal build once we have the managed-make solution for 1.2 under control.
> No promises on a timeline for this work however ...
> JohnC
> "Feico de Boer" <fdboer@baan.com> wrote in message
> news:bdgu5e$4fo$1@rogue.oti.com...
> > Hello folks,
> >
> > This week I got a first glimpse of the CDT and my first impression was
> quite
> > positive. After a better look however, I was a bit disapointed. Allthough
> > the CDT seems to work and you can actually do development, the current
> > implementation seems to be no more than a C/C++ editor/build facilitator,
> > not a real project management provider. In other words, it won't replace
> > Microsoft Visual Studio functionality yet ... (or I must be missing
> > something)
> >
> > Despite, still praise to the developers because they seem to have build a
> > nice foundation. And sure, Rome wasn't build in one day either.
> >
> > I couldn't find any documentation about future directions like what
> > functionality to be added and (aproximately) when.
> >
> > Features I would like to see:
> > - hide the makefile, fine to use it under water but I want it hidden from
> > the project
> > (no need to make ant build scripts when using the JDT)
> > - allow references to external shared libraries (or DLL's on WIN32)
> > (like external JAR references in the JDT)
> > - provide different types of projects (eg. executable; shared library;
> etc.)
> >
> > Any ideas, pointers or references about what can be expected?
> >
> > Just my 2 cents, regards,
> >
> > Feico de Boer
> >
> >
|
|
|
| Re: Future directions [message #75206 is a reply to message #75117] |
Mon, 07 July 2003 12:21 |
| Eclipse User |
|
|
|
Originally posted by: user.domain.invalid
Mike,
There is a lot of thinking going on about the build system and how it
relates to the core of CDT. A consensus seems to be forming that we need
to make the build system more like a service that would do, more or
less, exactly what you are proposing.
Basically, this discussion thread is probably the best problem statement
you could ask for. Feico, like a lot of people myself included, would
prefer to let the IDE do the work wherever it can. Hey, that's why we
invest in tooling, isn't it. However, we all recognize that due to the
diversity of tool chains, the IDE will eventually fail to build
something. That's when the fine grained control that only a generated
makefile provides comes in handy.
And what about ANT? Obviously, the open source work on the new ANT tasks
for C looks very promising. After all, it does a lot of the same stuff
our managed build model does and for a lot of target compilers too. But,
how widely adopted is the c-task variant of Ant in the embedded and
wider C/C++ development community and when will it be fully supported in
Ant? Basically, I see Ant as further subdividing an already fractured
set of build tools rather than replacing make any time soon. Of course,
this is my opinion, and maybe having tighter integration with CDT would
help spread the word among developers that Ant has a lot to offer.
I do not know if we will be able to close on a complete set of interface
requirements for the CDT 1.2 time frame. I think as a first step we will
move the build systems (managed and standard make) out of the core. From
there, we can start to abstract out the types of services that other
build system will have to provide.
For example, we already have a mechanism for registering build info
change events to the indexer. Maybe that is all a build system needs to
do for the core. After all, the workspace will deliver change
notifications to whatever builder you create; you just generate the
makefile/ANT file. That said, I think that going forward, a plug-in
build system will have to provide relevant information for the make
target view (good on Doug for bringing that up). Further, there should
be some way to register new project wizards and property pages so you
can provide the type of UI support you want.
Anyway, I hope that gives you a bit of an idea about the direction we
are going.
Mike Schneider wrote:
> John,
>
> Is it possible to define an api to build systems? You could
> define a set of build events and the build plugins would listen to the
> events and respond.
>
> plugins could be written for make, ant, Visual Studio, ..
>
> We have a very large system, and are migrating toward
> ant with custom build rules.
>
> The time based dependencies break down on very large systems.
> It is very useful to incorperate symantic change information
> to the build rules.
>
> Any thoughts on going to an build api with a defined set of build
> events?
>
> Thanks
> Mike
>
>
> John Camelon wrote:
>
>
>>Make is the first integration point because so many C++ projects (non
>>Microsoft ones anyway) currently use it. We have talked about supporting an
>>internal build once we have the managed-make solution for 1.2 under control.
>>No promises on a timeline for this work however ...
>
>
>>JohnC
>
>
>>"Feico de Boer" <fdboer@baan.com> wrote in message
>>news:bdgu5e$4fo$1@rogue.oti.com...
>>
>>>Hello folks,
>>>
>>>This week I got a first glimpse of the CDT and my first impression was
>>
>>quite
>>
>>>positive. After a better look however, I was a bit disapointed. Allthough
>>>the CDT seems to work and you can actually do development, the current
>>>implementation seems to be no more than a C/C++ editor/build facilitator,
>>>not a real project management provider. In other words, it won't replace
>>>Microsoft Visual Studio functionality yet ... (or I must be missing
>>>something)
>>>
>>>Despite, still praise to the developers because they seem to have build a
>>>nice foundation. And sure, Rome wasn't build in one day either.
>>>
>>>I couldn't find any documentation about future directions like what
>>>functionality to be added and (aproximately) when.
>>>
>>>Features I would like to see:
>>>- hide the makefile, fine to use it under water but I want it hidden from
>>>the project
>>>(no need to make ant build scripts when using the JDT)
>>>- allow references to external shared libraries (or DLL's on WIN32)
>>>(like external JAR references in the JDT)
>>>- provide different types of projects (eg. executable; shared library;
>>
>>etc.)
>>
>>>Any ideas, pointers or references about what can be expected?
>>>
>>>Just my 2 cents, regards,
>>>
>>>Feico de Boer
>>>
>>>
>>
>
>
|
|
|
| Re: Future directions [message #75224 is a reply to message #75206] |
Mon, 07 July 2003 12:41 |
| Eclipse User |
|
|
|
Hmm,
I should probably make sure my newsreader's settings are correct. That
last post was by me.
Sean Evoy
user@domain.invalid wrote:
> Mike,
> There is a lot of thinking going on about the build system and how it
> relates to the core of CDT. A consensus seems to be forming that we need
> to make the build system more like a service that would do, more or
> less, exactly what you are proposing.
>
> Basically, this discussion thread is probably the best problem statement
> you could ask for. Feico, like a lot of people myself included, would
> prefer to let the IDE do the work wherever it can. Hey, that's why we
> invest in tooling, isn't it. However, we all recognize that due to the
> diversity of tool chains, the IDE will eventually fail to build
> something. That's when the fine grained control that only a generated
> makefile provides comes in handy.
>
> And what about ANT? Obviously, the open source work on the new ANT tasks
> for C looks very promising. After all, it does a lot of the same stuff
> our managed build model does and for a lot of target compilers too. But,
> how widely adopted is the c-task variant of Ant in the embedded and
> wider C/C++ development community and when will it be fully supported in
> Ant? Basically, I see Ant as further subdividing an already fractured
> set of build tools rather than replacing make any time soon. Of course,
> this is my opinion, and maybe having tighter integration with CDT would
> help spread the word among developers that Ant has a lot to offer.
>
> I do not know if we will be able to close on a complete set of interface
> requirements for the CDT 1.2 time frame. I think as a first step we will
> move the build systems (managed and standard make) out of the core. From
> there, we can start to abstract out the types of services that other
> build system will have to provide.
>
> For example, we already have a mechanism for registering build info
> change events to the indexer. Maybe that is all a build system needs to
> do for the core. After all, the workspace will deliver change
> notifications to whatever builder you create; you just generate the
> makefile/ANT file. That said, I think that going forward, a plug-in
> build system will have to provide relevant information for the make
> target view (good on Doug for bringing that up). Further, there should
> be some way to register new project wizards and property pages so you
> can provide the type of UI support you want.
>
> Anyway, I hope that gives you a bit of an idea about the direction we
> are going.
>
> Mike Schneider wrote:
>
>> John,
>>
>> Is it possible to define an api to build systems? You could
>> define a set of build events and the build plugins would listen to the
>> events and respond.
>>
>> plugins could be written for make, ant, Visual Studio, ..
>>
>> We have a very large system, and are migrating toward ant with custom
>> build rules.
>>
>> The time based dependencies break down on very large systems.
>> It is very useful to incorperate symantic change information
>> to the build rules.
>>
>> Any thoughts on going to an build api with a defined set of build
>> events?
>>
>> Thanks
>> Mike
>>
>>
>> John Camelon wrote:
>>
>>
>>> Make is the first integration point because so many C++ projects (non
>>> Microsoft ones anyway) currently use it. We have talked about
>>> supporting an
>>> internal build once we have the managed-make solution for 1.2 under
>>> control.
>>> No promises on a timeline for this work however ...
>>
>>
>>
>>> JohnC
>>
>>
>>
>>> "Feico de Boer" <fdboer@baan.com> wrote in message
>>> news:bdgu5e$4fo$1@rogue.oti.com...
>>>
>>>> Hello folks,
>>>>
>>>> This week I got a first glimpse of the CDT and my first impression was
>>>
>>>
>>> quite
>>>
>>>> positive. After a better look however, I was a bit disapointed.
>>>> Allthough
>>>> the CDT seems to work and you can actually do development, the current
>>>> implementation seems to be no more than a C/C++ editor/build
>>>> facilitator,
>>>> not a real project management provider. In other words, it won't
>>>> replace
>>>> Microsoft Visual Studio functionality yet ... (or I must be missing
>>>> something)
>>>>
>>>> Despite, still praise to the developers because they seem to have
>>>> build a
>>>> nice foundation. And sure, Rome wasn't build in one day either.
>>>>
>>>> I couldn't find any documentation about future directions like what
>>>> functionality to be added and (aproximately) when.
>>>>
>>>> Features I would like to see:
>>>> - hide the makefile, fine to use it under water but I want it hidden
>>>> from
>>>> the project
>>>> (no need to make ant build scripts when using the JDT)
>>>> - allow references to external shared libraries (or DLL's on WIN32)
>>>> (like external JAR references in the JDT)
>>>> - provide different types of projects (eg. executable; shared library;
>>>
>>>
>>> etc.)
>>>
>>>> Any ideas, pointers or references about what can be expected?
>>>>
>>>> Just my 2 cents, regards,
>>>>
>>>> Feico de Boer
>>>>
>>>>
>>>
>>
>>
>
|
|
|
Goto Forum:
Current Time: Sun May 11 08:33:26 EDT 2025
Powered by FUDForum. Page generated in 0.06915 seconds |
Home