On Oct 19, 2012, at 6:11 PM, Dmitri Gribenko wrote:
> Thank you for the suggestion, I introduced OMPI_BUILD_FORTRAN_BINDINGS
> into mpi.h.in for this.
Excellent.
> *** JMS Per my above ramble, CHARACTER and INTEGER (and others) are
> built-in to Fortran, so we'll always have these if we're building
> Fortran at all. So how about simplifying these cases a little;
> perhaps something like:
> *** JMS I think these "2foo" types might be able to be simplified per
> my above ramble...?
>
> Simplified thanks to OMPI_BUILD_FORTRAN_BINDINGS.
w00t
> *** JMS Can we do anything with ## to simplify these macros a bit,
> perchance? (I haven't thought this through)
>
> +OMPI_DECLSPEC extern struct ompi_predefined_datatype_t ompi_mpi_logical1
> +#if OMPI_HAVE_FORTRAN_LOGICAL1
> + OMPI_ATTR_TYPE_TAG(ompi_fortran_logical1_t)
> +#endif
> + ;
>
> I could not think of anything that could help to simplify that part.
> All of these attributes are predicated on different conditions.
Ok. I mucked around a little and couldn't figure out a better way, either.
> typedef struct {
> ompi_fortran_real_t real;
> ompi_fortran_real_t imag;
> -} ompi_fortran_complex_t;
> +} ompi_fortran_complex_struct_t;
> #endif
>
> *** JMS I was initially curious as to why you renamed these, but now I
> see: it's because we added the same names into mpi.h.in. Do we really
> still need them here in ompi_config.h.in? I.e., aren't the
> definitions the same?
>
> They are different because macro names in mpi.h.in are defined to
> expand standard complex types' names (like float _Complex); there is
> special syntax to access real and imaginary parts of these. Types in
> ompi_config.h.in are custom structs that are layout-compatible with
> standard complex types; real and imaginary parts can be accessed with
> usual member access operators.
>
> So, while we could change op_base_functions.c that uses these structs
> to use standard syntax (and remove struct declarations), I doubt that
> it is desirable. As far as I understand, one should be able to build
> OpenMPI with a compiler that does not support standard complex types.
Correct.
This all now looks good to me (i.e., v5 of the patch); many thanks for your
perseverance and patience.
For me to commit this, can you do two things:
1. I hate to do this, but this is more than a "trivial" patch that we could
accept without attribution. Can you do one of two things:
1a. Sign a contributor agreement (almost identical to the Apache contributor
agreement): http://www.open-mpi.org/community/contribute/
1b. Send a v6 of your patch to this public mailing list with a
BSD-compatible license at the top, thereby releasing your patch under that
license (which is compatible with OMPI's).
2. Give me a short description that I can use to put into the README / FAQ /
etc. about what this functionality does, what prerequisites are needed (e.g.,
version of clang, etc.).
Many thanks!
--
Jeff Squyres
jsquy...@cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/
