RE: [cdt-dev] Architecture-specific switches redux

[Doug Schaefer <DSchaefer@xxxxxxx>]

Hmm, we should probably do debug that way, too. I've started working on GDB
Remote support similar to what Oyvind at Zylin has been offering. That
should be a separate feature. I guess our gdb mi should be separate too.

Lots of interesting combinations at any rate.

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC Member


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Doug Schaefer
> Sent: Tuesday, November 28, 2006 10:58 AM
> To: CDT General developers list.; cjashfor@xxxxxxxxxx
> Subject: RE: [cdt-dev] Architecture-specific switches redux
> 
> I think it's a trend we've started with the xlC integration, which is
> available as a separate feature on the CDT update site. We should be doing
> the same for cygwin, mingw, ppc-linux, and so on. Plus I'll be adding one
> for a Windows SDK integration.
> 
> So the user picks the CDT runtime and then picks the tools integration
> they
> want to use. We could even have composite features that include both to
> make
> it easier to get new users started.
> 
> Also, having an integration-less runtime also helps vendors that ship
> their
> integrations with their products and don't want to support the open source
> integrations.
> 
> Doug Schaefer, QNX Software Systems
> Eclipse CDT Project Lead, Tools PMC Member
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On
> > Behalf Of Chris Recoskie
> > Sent: Tuesday, November 28, 2006 9:43 AM
> > To: cjashfor@xxxxxxxxxx; CDT General developers list.
> > Subject: Re: [cdt-dev] Architecture-specific switches redux
> >
> > You can re-use the existing GCC build definitions by using the
> appropriate
> > entity's ID as the superClass attribute's ID.  If you look in the GCC
> > definitions, this is used by the various project types so that they do
> not
> > have to redefine the compiler in full each time they wish to use it.
> >
> > Using this mechanism, you could easily create a new plugin that inherits
> > the existing behaviour of the GCC integration, but adds the options you
> > are
> > looking for.  I think we could find a home for such a plugin somewhere
> in
> > the CDT.
> >
> > The issue of packaging which Doug mentions is an open issue that we need
> > to
> > sort out for 4.0.  It's obvious that we need separate GNU and Windows
> > (without GNU or CygWin or MinGW) flavours of CDT download (or just
> > features
> > on the update site?), but the form it would all take and how many other
> > flavours we'd have to support isn't a conversation we've really had yet.
> >
> > ===========================
> >
> > Chris Recoskie
> > Team Lead, IBM CDT Team
> > IBM Toronto
> > http://www.eclipse.org/cdt
> >
> >
> >
> >
> >   From:   Corey Ashford <cjashfor@xxxxxxxxxx>
> >
> >   To:     cdt-dev@xxxxxxxxxxx
> >
> >   Date:   27/11/2006 06:32 PM
> >
> >   Subject [cdt-dev] Architecture-specific switches redux
> >   :
> >
> >
> >
> >
> >
> > Hello,
> >
> > Let me first apologize for this long-winded email.
> >
> > Many months ago I sent an email to this list about adding some
> > architecture-specific switches to the CDT so that we can make it easier
> > for users of the PowerPC architecture to create 64-bit executables.
> >
> > Some discussion ensued and the conclusion came to was that the CDT team
> > would like to solve the issue of the many possible architecture-specific
> > (and other) switches, but not to add the switches one at a time in an
> > ad-hoc fashion.  We briefly discussed having gcc generate an XML
> > description of its switches to be consumed by the CDT, and the CDT would
> > dynamically generate a build tool settings page for that compiler.
> >
> > That XML-based solution would require a lot of engineering, well beyond
> > what we initially had in mind.
> >
> > So our group is still stuck at the point of wanting these 64-bit
> > switches to be available somehow, at the very least in the
> documentation.
> >
> > I have looked through the CDT documentation, and while it looks good and
> > seems to cover many topics, there is no section describing
> > architecture-specific compiler options.  I think there is an unwritten
> > assumption there that the developer knows he is using gcc and that the
> > gcc man pages is where he needs to look at to figure out which extra
> > switches are needed, if any.  Should this be written down?  Is there an
> > accepted way of adding compiler-specific info to the CDT docs?
> >
> > One alternative we have discussed in my group is to create a version of
> > the CDT that is tuned to the PowerPC and re-distribute it on a web site
> > like penguinppc.org.  I'd rather not have to do that if I can avoid it.
> >   Are there any known pratfalls in that approach, other than the obvious
> > maintenance issues?
> >
> > I also got to wondering if I could just create a small plug-in that
> > plugs into an extension point of org.eclipse.managedbuilder.gnu.ui, that
> > adds the switches using that.  However, it appears that
> > managedbuilder.gnu.ui doesn't have any extension points to plug into. I
> > am a new user/developer of plug-ins, so I may be missing the extension
> > point somehow.
> >
> > Any thoughts or suggestions on how to move forward with this issue would
> > be appreciated.
> >
> >
> > Regards,
> >
> > - Corey
> >
> >
> > --
> > Corey Ashford
> > Software Engineer
> > IBM Linux Technology Center, Linux Toolchain
> > Beaverton, OR
> > 503-578-3507
> > cjashfor@xxxxxxxxxx
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev