Did the mca_base_component_distill_checkpoint_ready paramter go away? Its intention was to allow a user to have a build with C/R compiled in and then choose at runtime if they want to restrict their component section to just C/R enabled components or not. I have reservations about that part of the patch.
If it is a compilation issue and that MCA parameter was lost, then I would leave the code in an #ifdef so we come back and make sure that functionality is preserved in the final version. I think if you fix the distill_checkpoint issue, then this patch is ok with me. As per my other messages, I agree with the comments from Jeff and Paul about existing code. I think a good compromise at this time would be to #ifdef out the code (so it is preserved for later re-design) and leave a big comment that we need to return there in the next stage. Leave the replacement code in a comment below it. Thanks! Josh On Thu, Dec 5, 2013 at 4:49 AM, Ralph Castain <r...@open-mpi.org> wrote: > Thanks Adrian - I think that will silence the questions in a fair way. > Appreciate your flexibility. > > Ralph > > > > On Thu, Dec 5, 2013 at 1:55 AM, Adrian Reber <adr...@lisas.de> wrote: > >> On Wed, Dec 04, 2013 at 08:07:39PM +0000, Jeff Squyres (jsquyres) wrote: >> > On Dec 4, 2013, at 11:29 AM, Ralph Castain <rhc.open...@gmail.com> >> wrote: >> > >> > > Jeff - you are jumping way ahead. I already said this needs further >> work to resolve blocking. These patches (per Adrian's email) just makes >> things compile >> > >> > Fair enough. >> > >> > But in some ways, having uncompilable code is a *good* thing, because >> it tells you exactly where you need to work on the architecture. Just >> updating it to *compile* removes that safeguard -- will you >> remember/re-find all those places where it *used* to block and convert the >> architecture to workaround the blocking? >> > >> > I guess I'm saying: what exactly does updating it to compile get for >> us, if we know the code still won't work? It seems like all we'll be doing >> is removing the grep-able places where we *know* we'll have to do work in >> the future. >> >> My goal was to let people see what I am doing and especially to decrease >> the number of patches I have to carry locally. I am not familiar enough >> with >> the Open MPI code (yet) to fix it correctly in the first try. Without >> having a code which compiles I personally cannot continue fixing the >> functionality. These patches are the first step which I wanted to make >> public. I can update the patches to include 'FIXME' in all the place if >> required. >> >> Adrian >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel >> > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Joshua Hursey Assistant Professor of Computer Science University of Wisconsin-La Crosse http://cs.uwlax.edu/~jjhursey
