On Wed, Jun 15, 2005 at 08:27:58PM -0400, Jeff Squyres wrote:
> On Jun 15, 2005, at 7:02 PM, Ben Allan wrote:
>
> Ah -- I thought that that would be a different issue (I presume you're
> speaking of the compile/lib flags command, like gnome-config et
> al.)...? Are you saying that the compile/lib flags should be
> accessible from ompi_info in a fine-grained fashion as well? (they're
> not right now -- only "compile flags" and "link flags")
As much info we can get, in as flexible a format as possible,
is the best thing I can imagine. And of course some attention
is needed so that from release to release, information output
is consistent with the prior releases, i.e. the labels don't
change gratuitously. What's called "c compiler" in one release
shouldn't be called ISO-C-compiler in the next.
New labels can be added, of course.
> That would obviate using the frameworks like gnome-config (which can
> read arbitrary *Conf.sh files), or ... er... I swear there was another
> one, but I can't seem to find it at the moment. I'm not saying that
> this is necessarily a Bad Thing; it's just something else that would
> need to be implemented.
Actually, i'm perfectly happy with a
ompiConf.sh provided there's an open-mpi-config that will
tell me where it sits (and maybe even query it for me).
> Did you look at the output when you run with the -parsable flag? (see
> my other mail about this)
I tried that just now and it doesn't look different. Will check your
other mail (which apparently i haven't reached yet in the mail reader).
I take that back, apparently -parseable isn't recognized but -parsable
is. A :-separated output results. tolerable. :)
Kudos to you all, actually. I haven't seen anything this useful
from the mpich team yet. {now matt can correct me...}
> I'm still not sure that you're getting what you want, though. Note
> that there's two sets of flags provided by "ompi_info -all" -- the
> flags that Open MPI was built with and the flags that are added by the
> wrapper compilers. Are you just extracting the wrapper compiler flags?
> Are they sufficient?
It is useful to know both.
> Also note that the wrapper compilers will report their flags to you as
> well:
>
> mpicc -showme
> mpicc -showme:compile
> mpicc -showme:link
As usual, mpicc --help doesn't show showme as an option.
> Finally, is there a reason you can't just use the wrapper compilers
> themselves? They can even be layered with other compilers if
> necessary. Unless there's a technical reason that you can't, I would
> strongly advise using the wrapper compilers -- we wrote them for
> exactly this purpose.
I love it when compiler wrappers work.
But in the context of
multi-language builds,
cranky c++ and fortran compilers competing for who gets to link
either the executable or construct the shared library,
mis-installations by sysadmins,
portability to horrors like AIX, etc, all wrappers are
taken with a grain of salt.
My users expect to combine c,c++,fortran,python,java(!),and fortran-variant-x
all in the same executable on a diversity of platforms.
And when it doesn't work, they don't go to you, they
tell me "hey, make it work, my mpi isn't broken -- it
runs my vanilla C code all the time." The real issue is,
of course, the utter insanity of history that is the linker.
The workaround always involves reverse-engineering the
compiler wrappers and assembling the link line details
explicitly. Far better that this kind of insanity be
testable and the work-arounds picked out by my configure
scripts than all the users coming back to me for
individual attention.
> help messages as of yet. Don't worry; they will be there in the
> not-distant future (look at LAM's documentation and verbose help
> messages as an example: I believe in good error messages).
Looking forward to it.
> > Please, extract the full path name to the compilers your
> > wrappers are going to invoke and put them in ompi_info.
>
> Actually, it is whatever was given to configure. In this case, only
> "gcc" was given to configure. For example, if you:
>
> with
>
> ./configure CC=/path/to/gcc
>
> You'll see:
>
> C compiler: /path/to/gcc
>
> And that's also the name that mpicc will fork/exec to compile C
> applications. I'd prefer to leave it this way for the following
> reasons:
>
> - this is the way that I've seen most Autoconf-enabled build systems
> work
> - if people want to use absolute names for compilers, they can
> - those who don't want absolute names aren't forced to (there's many an
> installation out there that only has the C bindings and don't give a
> whit about C++ or Fortran)
>
Those are all fine reasons, and i'm not saying (since for example)
compiler:c:command:gcc
should be changed to read
compiler:c:command:/some/godawful/experimental/gcc
No, i want whatever is there to keep going just as is so that
no existing build processes break.
I'm just requesting that be added:
compiler:which_c:command:/usr/local/bin/gcc
compiler:which_f77:command:/opt/intel/whatever
compiler:which_cxx:command:/opt/intel/whatever
where which_$X indicates the full path to the
critter X that was built with.
In some fantasy future I might then be able to
submit a patch to the c++/fortran compiler wrapper so that
if the wrapper is used in an environment where
the compiler invoked is not the same as the
compiler open-mpi libraries were built with I could
issue a compiler warning. This would save a lot
of headaches to a lot of naive users.
The autoconf process, if ompi_info is to be believed,
checks a lot of machine specific and compiler specific
things to do with alignment, size, type existence, etc
and records these assumptions. Throwing a random
compiler (or worse, the primitive size-changing fortran switches)
into a compiler wrapper's path is just asking for trouble.
We need good config info to diagnose these kinds of user idiocy
efficiently.
Thanks,
Ben
