Re: [cdt-dev] Re: [ptp-dev] Compiler support

[wspear <wspear@xxxxxxxxxxxxxx>]

Thanks Chris,

I'm digging into the MBS extensibility documentation and the relevant
xml files in the MBS plugins right now.  It looks like everything we
need is here, with some assembly required.  Total generic compiler
support isn't necessary as long as we can turn off the options that
kill the compiler(s) in question.  Text fields for manual entry of
their diverse options should be fine for the time being.

Regards,

Wyatt

On 7/27/07, Chris Recoskie <recoskie@xxxxxxxxxx> wrote:
> 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
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>