Re: [OMPI devel] RFC: Remove --without-hwloc configure option

I think we already do, but I can check > On Sep 4, 2015, at 6:06 AM, Gilles Gouaillardet > wrote: > > iirc, hwloc can read input from an xml file. > if not already the case, should we provide a simple mechanism to tell hwloc > not to detect the topology from the os but from a config file. > fo

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

iirc, hwloc can read input from an xml file. if not already the case, should we provide a simple mechanism to tell hwloc not to detect the topology from the os but from a config file. for example, if working on a new os and/or hardware, then manually generate the hwloc xml file on each node and do

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

It sounds, then, like removing —without-hwloc will do no harm. At worst, hwloc might report inaccurate info, but that won’t stop us from running with appropriate cmd line options (e.g., to set the #slots and bind-to none). Unless there are any further concerns, I’ll prep the PR > On Sep 4, 201

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Brice, I'm a developer of Fujitsu MPI for K computer and Fujitsu PRIMEHPC FX10/FX100 (SPARC-based CPU). Though I'm not familiar with the hwloc code and didn't know the issue reported by Gilles, I also would be able to help you to fix the issue. Takahiro Kawashima, MPI development team, Fujitsu

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Thanks Brice, bottom line, even if hwloc is not fully ported, it should build and ompi should get something usable. in this case, i have no objection removing the --without-hwloc configure option. you can contact me off-list regarding the FX10 specific issue Cheers, Gilles On 9/4/2015 2:31

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Le 04/09/2015 00:36, Gilles Gouaillardet a écrit : > Ralph, > > just to be clear, your proposal is to abort if openmpi is configured > with --without-hwloc, right ? > ( the --with-hwloc option is not removed because we want to keep the > option of using an external hwloc library ) > > if I understa

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

I see - yes, that would be true. It would not build without hwloc. An alternative would be to have hwloc return a neutral response that we check and ignore if hwloc isn’t “active”. Would that suffice? I’m just looking to remove all that #if cruft all over the place. > On Sep 3, 2015, at 4:02 PM

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Gilles, You have the nature of my question correct. To restate: Imagine somebody is developing an experimental platform (such as a research OS) and they want an MPI for it. Additionally assume that hwloc (the embedded one or otherwise) doesn't build at all for this platform. It is my understandin

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

Ralph, just to be clear, your proposal is to abort if openmpi is configured with --without-hwloc, right ? ( the --with-hwloc option is not removed because we want to keep the option of using an external hwloc library ) if I understand correctly, Paul's point is that if openmpi is ported to a new

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

No - hwloc is embedded in OMPI anyway. > On Sep 3, 2015, at 11:09 AM, Paul Hargrove wrote: > > > On Thu, Sep 3, 2015 at 8:03 AM, Ralph Castain > wrote: > Does anyone know of a reason why we shouldn’t do this? > > > Would doing this mean that a port to a new system w

Re: [OMPI devel] RFC: Remove --without-hwloc configure option

On Thu, Sep 3, 2015 at 8:03 AM, Ralph Castain wrote: > Does anyone know of a reason why we shouldn’t do this? > Would doing this mean that a port to a new system would require that one first perform a full hwloc port? -Paul -- Paul H. Hargrove phhargr...@lbl.gov Comp

[OMPI devel] RFC: Remove --without-hwloc configure option

Hi folks We have carried the ability to build without hwloc since we first pulled that package into OMPI. This made sense initially as the code was still maturing, and we were concerned about the breadth of support. However, that has certainly changed, and I propose we remove this configure opt