Ralph,
As a practical matter most users probably aren't going to know what to do
with anything that scrolls off their screen.
So I think dumping the ompi_info output as-is would be just "noise" to many
folks.
That is one reason I didn't just suggest doing exactly that
(cross-compilation being another)
However, a suitably summarized output might be just the right thing.
Perhaps something compact along the lines of
MCA foo: component1 component2 component2
MCA foobar: componentA componentB
...
Bindings: C C++ Java Fortan(mpif.h 'use mpi')
If this could information be generated at the end of configure, rather than
"make install", it could save folks some time spent compiling incorrectly
configured builds.
Another thing one might independently want to consider is having configure
warn when the required libs are present for a component but the "can
compile" test fails.
This would, for instance, catch the situation when the "libfoo" packages is
installed but the "libfoo-dev" package is not.
This approach, however, may require non-trivial changes to how all the
configure probes are performed since I don't believe this is something
autoconf has existing support for (the AC_CHECK_LIB macro is effectively a
check for the "libfoo-dev" package only).
Just my $0.02USD, of course.
-Paul
On Mon, Jan 25, 2016 at 1:46 PM, Ralph Castain <r...@open-mpi.org> 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
>
--
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
