[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] Re: [ptp-dev] Compiler support
|
Hi Wyatt,
Luckily (unluckily? :-P ) for you I lurk on ptp-dev... cross-posting to
cdt-dev too...
The idea behind managed build is that if you have to support another
compiler, you write some new plugin.xml to support it. If your compiler
behaves sufficiently close to GCC/G++ then you can probably get away with
just extending the compiler definitions already there and just overriding
some things (there is a notion of subclassing). Or, you could hide the
options that your compiler doesn't support. I would say that Manged Build
is already pretty tolerant of other toolchains because of this.
It sounds like what you want is to have a toolchain that's fully editable
in the UI. It's an interesting idea, but in order to make it functional
enough to even support the average toolchain, I think you will essentially
end up replicating all of the stuff that we already have in the managed
build extension point. While it may be advantageous to users to not force
them to learn how to create Eclipse plug-ins in order to create a new
toolchain or tweak an existing one, I think the effort you'd have to expend
in order to make a full-fledged GUI-based tool editor would make it not
worth it. The capability is already there and the Managed Build System is
actually one of the few decently documented areas of CDT, so I think that
compiler integrators would have a relatively OK time of integrating a
toolchain once they get over the initial learning curve of Eclipse..
I'm not sure about the specifics of the compilers you're trying to support,
but in general it is very hard to do a generic toolchain that can support
almost everything. All the compilers pretty much seem to have their own
little quirks, and if you really tried to keep to the lowest common
denominator then I don't think you'd have much left in your generic
compiler. However this idea might still be useful if you think in terms of
creating a simple toolchain that can be subclassed so that people can fill
in the rest with their own extensions, rather than an actual toolchain that
people are going to try to run. Again though, it depends on how much all
the compilers you are trying to support actually have in common.
Anyway, just my $0.02 CDN. I don't want to discourage anyone from any
ideas that they think add value.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
wspear
<wspear@cs.uorego
n.edu> To
Sent by: "Parallel Tools Platform general
ptp-dev-bounces@e developers" <ptp-dev@xxxxxxxxxxx>
clipse.org cc
Subject
27/07/2007 03:17 [ptp-dev] Compiler support
PM
Please respond to
Parallel Tools
Platform general
developers
<ptp-dev@eclipse.
org>
Greetings,
As Eclipse and the PTP have increased in interest to TAU users we've
been encountering compatibility problems with people's projects.
These issues are more fundamental than TAU or PTP functionality. The
CDT's managed make system makes assumptions that can make compiling a
project with 'Other' compilers excessively complicated or impossible.
For example, PGI compilers can't handle any of the standard -O
optimization flags, but there isn't a way to turn them off in the
managed build system. I believe this is the only irremovable option,
but the need to adjust and disable other unrecognized options has been
annoying too.
Supporting scientific and high performance software developers means
supporting some of the more esoteric compilers as well as compiler
wrapper scripts provided by various MPI versions. As far as I am
aware CDT only officially supports gnu, Intel and IBM compilers.
Rather than create a new compiler configuration for every possible
compiler, I suggest a generic compiler configuration that makes no
assumptions whatsoever about what options a compiler may or may not
recognize, or at least one that allows the full editing or removal of
its compiler options and defaults to a minimal set.
I've started looking at the CDT's build-configuration plugins, but I
am not sure if this is something I should suggest to the CDT or
something that ought to be worked on under the PTP's banner. However,
until the managed builder becomes more tolerant of compiler diversity,
we have potential users who aren't going to be able to enjoy the whole
TAU/Eclipse/PTP package.
Does anyone have any thoughts on this, or know of a project already in
the works that might address the issue?
Thanks,
Wyatt
_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev
