On Fri, Sep 23, 2011 at 2:55 AM, Jeff Squyres <jsquyres_at_[hidden]> wrote:
> On Sep 22, 2011, at 4:39 PM, Uday Kumar Reddy B wrote:
>>> More specifically: how is mpicc supposed to know that any given option was intended for mpicc and not the underlying compiler, particularly the ones that it doesn't support?
>> Yes, it won't in the general case, but since -cc is accepted by mpich, you can as well assume it is not intended for the underlying compiler. If a user is indeed trying to pass -cc to some unknown compiler, the code is anyway not going to work with MPICH and probably most other MPIs. In any case, for portability purposes, shouldn't you support -cc?
> That would mean that we have to support all the CLI options for MPICH's mpicc. And they would likewise need to support ours. And we should also support Platform MPI's mpicc options. And ...
> It's a slippery slope, and we're not really willing to go down it.
> The real problem is that wrapper compilers are not standardized. Cray doesn't have one, for example (IIRC). And IBM AIX MPI doesn't either (also IIRC -- could be wrong on both of these). Users are unfortunately left in a lurch, and have to work around these issues in their application build systems. :-(
Okay. BTW, mpicc only has 7 cmdline options, and you probably already
support some of them (-show), and they are all provided for good
reason. And we all know that MPI is all about portability...
>> Or one could end up with distributions that compile on some or don't on another. If you indeed would not like to support it, it's better to check for -cc and throw an error than compile with a compiler user didn't intend to - the latter may go unnoticed.
> What's the advantage to having mpicc throw the error vs. the underlying compiler?
Sorry, I was confused; there isn't.
> Jeff Squyres
> For corporate legal information go to:
> users mailing list