January 2014 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] build broken on 'master': 'mpitypedefs.h' file not found
by Rob Latham 05 Jan '14

05 Jan '14

On Sat, Jan 04, 2014 at 08:08:16PM -0600, Jed Brown wrote: > Rob, this commit does not build, at least not if you configure out of > source. Jenkins did not find a problem with this commit, so I'd like to understand what's different in your environment. > commit 3146e104017114b0e9a7e04824cfeb7383155d12 > Author: Rob Latham <robl(a)mcs.anl.gov> > Date: Fri Jan 3 12:35:21 2014 -0600 > > bring back include file needed for MPI_AINT_CAST_TO_VOID_PTR > > In romio-standalone fixes, I zapped the inclusion of mpitypedefs.h, but > the "ensure this large value fits into pointer without overflowing" > check relied on some MPICH-internal macros/routines. Only Blue Gene > driver uses those routines, so nightly tests didn't flag it. > > No reviewer. > > diff --git a/src/mpi/romio/adio/include/adioi.h b/src/mpi/romio/adio/include/adioi.h > index ea07491..0553dfb 100644 > --- a/src/mpi/romio/adio/include/adioi.h > +++ b/src/mpi/romio/adio/include/adioi.h > @@ -824,6 +824,7 @@ int ADIOI_MPE_iwrite_b; > /* Use MPID_Ensure_Aint_fits_in_pointer from mpiutil.h and > MPI_AINT_CAST_TO_VOID_PTR from configure (mpi.h) */ > #include "glue_romio.h" > + #include "mpitypedefs.h" /* for MPI_AINT_CAST_TO_VOID_PTR */ > > #define ADIOI_AINT_CAST_TO_VOID_PTR (void*)(MPIR_Pint) > /* The next two casts are only used when you don't want sign extension > > > /bin/sh ./libtool --tag=CC --mode=compile clang -DHAVE_CONFIG_H -I. -I../../../../src/mpi/romio -I./adio/include -I/home/jed/src/mpich/build-clang/src/include -I./include -I../../../../src/mpi/romio/include -I./mpi-io -I../../../../src/mpi/romio/mpi-io -I./adio/include -I../../../../src/mpi/romio/adio/include -I/home/jed/src/mpich/build-clang/src/mpl/include -I/home/jed/src/mpich/src/mpl/include -I/home/jed/src/mpich/src/openpa/src -I/home/jed/src/mpich/build-clang/src/openpa/src -I/home/jed/src/mpich/build-clang/src/mpi/romio/include -O2 -DFORTRANUNDERSCORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_ROMIOCONF_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT mpi-io/close.lo -MD -MP -MF $depbase.Tpo -c -o mpi-io/close.lo ../../../../src/mpi/romio/mpi-io/close.c &&\ > mv -f $depbase.Tpo $depbase.Plo > libtool: compile: clang -DHAVE_CONFIG_H -I. -I../../../../src/mpi/romio -I./adio/include -I/home/jed/src/mpich/build-clang/src/include -I./include -I../../../../src/mpi/romio/include -I./mpi-io -I../../../../src/mpi/romio/mpi-io -I./adio/include -I../../../../src/mpi/romio/adio/include -I/home/jed/src/mpich/build-clang/src/mpl/include -I/home/jed/src/mpich/src/mpl/include -I/home/jed/src/mpich/src/openpa/src -I/home/jed/src/mpich/build-clang/src/openpa/src -I/home/jed/src/mpich/build-clang/src/mpi/romio/include -O2 -DFORTRANUNDERSCORE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_ROMIOCONF_H -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -MT mpi-io/close.lo -MD -MP -MF mpi-io/.deps/close.Tpo -c ../../../../src/mpi/romio/mpi-io/close.c -fPIC -DPIC -o mpi-io/.libs/close.o > In file included from ../../../../src/mpi/romio/mpi-io/close.c:8: > In file included from ../../../../src/mpi/romio/mpi-io/mpioimpl.h:15: > In file included from ../../../../src/mpi/romio/adio/include/adio.h:440: > ../../../../src/mpi/romio/adio/include/adioi.h:827:12: fatal error: 'mpitypedefs.h' file not found > #include "mpitypedefs.h" /* for MPI_AINT_CAST_TO_VOID_PTR */ > ^ > 1 error generated. > > > > Now my understanding is that ROMIO is still supposed to be buildable > outside the MPI source tree, in which case src/include/mpitypedefs.h > will not be available. I don't know how you want to fix this. Yeah, in the standalone ROMIO case I do not include that mpich-specific header, and MPI_AINT_CAST_TO_VOID_PTR becomes nothing thanks to macro magic. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Pavan Balaji 05 Jan '14

05 Jan '14

On Jan 5, 2014, at 11:59 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >> Essentially, it’s what we define it to be. I guess we could have used >> “Reviewed-by”, but I’m not sure it really matters that much. > > FWIW, I think it's a needless deviation from a widespread convention. I’ll bring this up at the next group meeting and see what the other developers think. — Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jeff Hammond 05 Jan '14

05 Jan '14

God help us all if any programmer waivers from the impeccable logic bestowed upon on us lowly humans by the GNU/Linux developer community. Clearly, there is no room for any other self-consistent convention and developer teams that attempt to use one are doomed to fail in every aspect of their professional lives. Jeff On Sun, Jan 5, 2014 at 11:59 AM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: > Pavan Balaji <balaji(a)mcs.anl.gov> writes: > >> AFAIK, signedoff has project specific meaning. > > As far as I know, there are only two meanings, the one used by MPICH and > the meaning used by the kernel, git.git, AOSP/Gerrit/Google, and other > projects. If someone searches the web, all the results will use that > meaning (DCO). > > https://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… > https://github.com/wking/signed-off-by > >> Essentially, it’s what we define it to be. I guess we could have used >> “Reviewed-by”, but I’m not sure it really matters that much. > > FWIW, I think it's a needless deviation from a widespread convention. > >> But you are right, we should document it some place. Maybe the wiki? > > Sure, or a CONTRIBUTING document in the repo (easier to search). -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)anl.gov / jhammond(a)uchicago.edu / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 05 Jan '14

05 Jan '14

Pavan Balaji <balaji(a)mcs.anl.gov> writes: > AFAIK, signedoff has project specific meaning. As far as I know, there are only two meanings, the one used by MPICH and the meaning used by the kernel, git.git, AOSP/Gerrit/Google, and other projects. If someone searches the web, all the results will use that meaning (DCO). https://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-in-… https://github.com/wking/signed-off-by > Essentially, it’s what we define it to be. I guess we could have used > “Reviewed-by”, but I’m not sure it really matters that much. FWIW, I think it's a needless deviation from a widespread convention. > But you are right, we should document it some place. Maybe the wiki? Sure, or a CONTRIBUTING document in the repo (easier to search).

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Pavan Balaji 05 Jan '14

05 Jan '14

On Jan 4, 2014, at 10:21 PM, Jed Brown <jedbrown(a)mcs.anl.gov> wrote: >> We use signoff as a way to get a second confirmation on the >> correctness of the patch. > > All the projects following Linux kernel conventions (where > "Signed-off-by" was invented) use Reviewed-by (and Acked-by or > Tested-by) for this. I would recommend changing because it creates > confusion and I don't see a tangible benefit to using the terms > differently from conventional usage. Regardless, conventions like these > are good to have in the developer documentation. AFAIK, signedoff has project specific meaning. Essentially, it’s what we define it to be. I guess we could have used “Reviewed-by”, but I’m not sure it really matters that much. But you are right, we should document it some place. Maybe the wiki? >> In some cases, multiple confirmations. There’s also a "silent >> signoff” done by the jenkins testing before things are merged into >> mpich/master. > > I thought the tests were on jenkins-ci.mcs.anl.gov, but I don't see it > there any more. In any case, 'master' is currently not buildable (see > my other mail). They are here: https://jenkins.mpich.org/ — Pavan -- Pavan Balaji http://www.mcs.anl.gov/~balaji

1 0

Re: [mpich-devel] [mpich-discuss] Use of Signed-off-by in MPICH
by Jed Brown 04 Jan '14

04 Jan '14

Pavan Balaji <balaji(a)mcs.anl.gov> writes: > Please use devel(a)mpich.org for developer oriented discussion. Okay, moving it. > We use signoff as a way to get a second confirmation on the > correctness of the patch. All the projects following Linux kernel conventions (where "Signed-off-by" was invented) use Reviewed-by (and Acked-by or Tested-by) for this. I would recommend changing because it creates confusion and I don't see a tangible benefit to using the terms differently from conventional usage. Regardless, conventions like these are good to have in the developer documentation. > In some cases, multiple confirmations. There’s also a "silent > signoff” done by the jenkins testing before things are merged into > mpich/master. I thought the tests were on jenkins-ci.mcs.anl.gov, but I don't see it there any more. In any case, 'master' is currently not buildable (see my other mail).

1 0