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
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
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.
On Thu, Dec 5, 2013 at 4:49 AM, Ralph Castain <rhc_at_[hidden]> wrote:
> Thanks Adrian - I think that will silence the questions in a fair way.
> Appreciate your flexibility.
> On Thu, Dec 5, 2013 at 1:55 AM, Adrian Reber <adrian_at_[hidden]> 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.openmpi_at_[hidden]>
>> > > 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
>> 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
>> devel mailing list
> devel mailing list
Assistant Professor of Computer Science
University of Wisconsin-La Crosse