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. :-( > 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? -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
