I don't know if I agree here. 1. Everything about what configure is going to do is already sent to stdout (yes, I know, people don't look at things that scroll off their screen). But the point is -- if they want to grep for output, they can already do so.
2. I think it would be incredible challenging to make a list at the end of configure (or make install -- take your pick) that a) shows all the optional things that Open MPI is (and/or is not) installing, b) does not scroll of the screen, and c) isn't a super-dense eye chart that people will just end up ignoring anyway. 2a. It's a slippery slope to say "Well, we'll only show the *important* things that Open MPI is/is not installing," because even if you start with a short list, a) people won't read it anyway ;-), and b) that list will grow over time such that it ultimately will result in a super-dense eye chart. This is why I tend to like the MPI application run-time kinds of solutions: it just seems like there's a higher probability that people will notice those messages, because a) everyone ignores configure/make install output (if they didn't they're know what OMPI was/was not installing), b) when a show_help message is emitted, it breaks up the [familiar] output of the user's application, and therefore is easy to recognize as "whoa, that's an error message that I should probably read." Just my $0.02. > On Jan 25, 2016, at 5:23 PM, Paul Hargrove <phhargr...@lbl.gov> wrote: > > Ah, Nathan read my mind! > This is (more or less) what I suggest in the post I was typing when Nathan's > post arrived. > > -Paul > > On Mon, Jan 25, 2016 at 2:13 PM, Nathan Hjelm <hje...@lanl.gov> wrote: > > Another thing that might be useful is at the end of configure print out > a list of each framework with a list of components and some build info > (static vs dynamic, etc). Something like: > > plm: > alps (dynamic) > rsh (dynamic) > tm (dynamic) > > -Nathan > > On Mon, Jan 25, 2016 at 01:46:44PM -0800, Ralph Castain wrote: > > That makes sense, Paul - what if we output effectively the ompi_info > > summary of what was built at the end of the make install procedure? Then > > you would have immediate feedback on the result. > > On Mon, Jan 25, 2016 at 1:27 PM, Paul Hargrove <phhargr...@lbl.gov> > > wrote: > > > > As one who builds other people's software frequently, I have my own > > opinions here. > > Above all else, is that there is no one "right" answer, but that > > consistency with in a product is best. > > So (within reason) the same things that work to configure module A and > > B > > should work with C and D as well. > > To use an analogy from (human) languages, I dislike "irregular verbs". > > The proposal to report (at run time) the existence of TM support on the > > system (but lacking in ORTE), doesn't "feel" consistent with existing > > practice. > > In GASNet we *do* report at runtime if a high-speed network is present > > and you are not using it. > > For instance we warn if the headers were missing at configure time but > > we can see the /dev entry at runtime. > > However, we do that uniformly across all the networks and have done > > this > > for years. > > So, it is a *consistent* practice in that project. > > Keep It Simple Stupid is also an important one. > > So, I agree with those who think the proposal to catch this at runtime > > is an unnecessary complication. > > I think improving the FAQ a good idea > > I do, however, I can think of one thing that might help the "I thought > > I > > had configured X" problem Jeff mentions. > > What about a summary output at the end of configure or make? > > Right now I sometimes use something like the following: > > $ grep 'bindings\.\.\. yes' configure.out > > $ grep -e 'component .* can compile\.\.\. yes' configure.log > > This lets me see what is going to be built. > > Outputing something like this a the end of configure might encourage > > admins to check for their feature X before typing "make" > > The existing configury goop can easily be modified to keep a list of > > configured components and language bindings. > > However, another alternative is probably easier to implement: > > The last step of "make install" could print a message like > > NOTICE: Your installation is complete. > > NOTICE: You can run ompi_info to verify that all expected components > > and language bindings have been built. > > -Paul > > On Mon, Jan 25, 2016 at 11:13 AM, Jeff Squyres (jsquyres) > > <jsquy...@cisco.com> wrote: > > > > Haters gotta hate. ;-) > > > > Kidding aside, ok, you make valid points. So -- no tm "addition". > > We > > just have to rely on people using functionality like "--with-tm" in > > the configure line to force/ensure that tm (or whatever feature) will > > actually get built. > > > > > On Jan 25, 2016, at 1:31 PM, Ralph Castain <r...@open-mpi.org> > > wrote: > > > > > > I think we would be opening a real can of worms with this idea. > > There are environments, for example, that use PBSPro for one part of > > the system (e.g., IO nodes), but something else for the compute > > section. > > > > > > Personally, I'd rather follow Howard's suggestion. > > > > > > On Mon, Jan 25, 2016 at 10:21 AM, Nathan Hjelm <hje...@lanl.gov> > > wrote: > > > On Mon, Jan 25, 2016 at 05:55:20PM +0000, Jeff Squyres (jsquyres) > > wrote: > > > > Hmm. I'm of split mind here. > > > > > > > > I can see what Howard is saying here -- adding complexity is > > usually a bad thing. > > > > > > > > But we have gotten these problem reports multiple times over the > > years: someone *thinking* that they have built with launcher support > > X > > (e.g., TM, LSF), but then figuring out later that things aren't > > running as expected, and after a bunch of work, figure out that it's > > because they didn't build with support X. > > > > > > > > Gilles idea actually sounds interesting -- if the tm module > > detect > > some of the sentinel PBS/TM env variables, emit a show_help() if we > > don't have full TM support compiled in. This would actually save > > some > > users a bunch of time and frustration. > > > > > > > > --> Keep in mind that the SLRUM launcher is different, because > > it's all CLI-based (not API-based) and therefore we always build it > > (because we don't have to find headers and libraries). > > > > > > > > FWIW, we do have precedent of having extra MCA params for users > > to > > turn off warnings that they don't want to see. > > > > > > > > I guess the question here is: is there a valid use case for > > running in PBS/Torque and *not* wanting to use the TM launcher? > > > > > > Once case comes to mind. In the case of Cray systems that > > unfortunately > > > run Moab/Toque we can launch using either alps or torque (Howard > > correct > > > me if I am wrong). When Sam and I originally wrote the XE support > > we > > > used alps instead of torque. I am not entirely sure what we do now. > > > > > > -Nathan > > > > > > _______________________________________________ > > > devel mailing list > > > de...@open-mpi.org > > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2016/01/18509.php > > > > > > _______________________________________________ > > > devel mailing list > > > de...@open-mpi.org > > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2016/01/18510.php > > > > -- > > Jeff Squyres > > jsquy...@cisco.com > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/ > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2016/01/18511.php > > > > -- > > Paul H. Hargrove phhargr...@lbl.gov > > Computer Languages & Systems Software (CLaSS) Group > > Computer Science Department Tel: +1-510-495-2352 > > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2016/01/18513.php > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > > Link to this post: > > http://www.open-mpi.org/community/lists/devel/2016/01/18514.php > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/01/18515.php > > > > -- > Paul H. Hargrove phhargr...@lbl.gov > Computer Languages & Systems Software (CLaSS) Group > Computer Science Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > _______________________________________________ > devel mailing list > de...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel > Link to this post: > http://www.open-mpi.org/community/lists/devel/2016/01/18517.php -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
