rg] on behalf of Ralph Castain
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support
On May 16, 2014, at 1:03 PM, Fabricio Cannini
mailto:fcann...@gmail.com>> wrote:
Em 16-05-2014 10:06, Jeff Squyres (jsqu
gt; >> Nada, zilch, nothing on standard OS X install. I do not want to put an
> >> extra
> requirement on my users. Nor do I want something as simple-minded as CMake.
> autotools works great for me.
> >>
> >> -Nathan
> >>
> >>
From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support
On May 16, 2014, at 1:03 PM, Fabricio Cannini
mailto:fca
Em 16-05-2014 17:07, Ralph Castain escreveu:
FWIW, simply for my own curiosity's sake, if someone could confirm
deny whether cmake:
1. Supports the following compiler suites: GNU (that's a given, I
assume), Clang, OS X native (which is variants of GNU and Clang),
Absoft, PGI, Intel, Cray, HP-UX,
want something as simple-minded as CMake.
> autotools works great for me.
>
> -Nathan
>
>
> From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
> [r...@open-mpi.org]
> Sent: Friday, May 16, 2014 2:07 PM
> To: Open M
.
autotools works great for me.
-Nathan
From: users [users-boun...@open-mpi.org] on behalf of Ralph Castain
[r...@open-mpi.org]
Sent: Friday, May 16, 2014 2:07 PM
To: Open MPI Users
Subject: Re: [OMPI users] Question about scheduler support
On May 16, 2014
On May 16, 2014, at 1:03 PM, Fabricio Cannini wrote:
> Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
>> On May 15, 2014, at 8:00 PM, Fabricio Cannini
>> wrote:
>>
Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has iss
Em 16-05-2014 10:06, Jeff Squyres (jsquyres) escreveu:
On May 15, 2014, at 8:00 PM, Fabricio Cannini
wrote:
Nobody is disagreeing that one could find a way to make CMake
work - all we are saying is that (a) CMake has issues too, just
like autotools, and (b) we have yet to see a compelling reas
Le 2014-05-16 09:06, Jeff Squyres (jsquyres) a écrit :
On May 15, 2014, at 8:00 PM, Fabricio Cannini wrote:
Nobody is disagreeing that one could find a way to make CMake work - all we are
saying is that (a) CMake has issues too, just like autotools, and (b) we have
yet to see a compelling re
On May 15, 2014, at 8:00 PM, Fabricio Cannini wrote:
>> Nobody is disagreeing that one could find a way to make CMake work - all we
>> are saying is that (a) CMake has issues too, just like autotools, and (b) we
>> have yet to see a compelling reason to undertake the transition...which
>> woul
Em 15-05-2014 20:48, Ralph Castain escreveu:
Nobody is disagreeing that one could find a way to make CMake work - all we are
saying is that (a) CMake has issues too, just like autotools, and (b) we have
yet to see a compelling reason to undertake the transition...which would have
to be a *very
Nobody is disagreeing that one could find a way to make CMake work - all we are
saying is that (a) CMake has issues too, just like autotools, and (b) we have
yet to see a compelling reason to undertake the transition...which would have
to be a *very* compelling one.
On May 15, 2014, at 4:45 PM
Em 15-05-2014 20:15, Maxime Boissonneault escreveu:
Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?
OMPI has a long, deep history wi
On May 15, 2014, at 4:15 PM, Maxime Boissonneault
wrote:
> Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
>> On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
>>
>>> Alright, but now I'm curious as to why you decided against it.
>>> Could please elaborate on it a bit ?
>> OMPI has
Le 2014-05-15 18:27, Jeff Squyres (jsquyres) a écrit :
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
Alright, but now I'm curious as to why you decided against it.
Could please elaborate on it a bit ?
OMPI has a long, deep history with the GNU Autotools. It's a very long,
complicated
On May 15, 2014, at 6:14 PM, Fabricio Cannini wrote:
> Alright, but now I'm curious as to why you decided against it.
> Could please elaborate on it a bit ?
OMPI has a long, deep history with the GNU Autotools. It's a very long,
complicated story, but the high points are:
1. The GNU Autotools
Em 15-05-2014 18:40, Ralph Castain escreveu:
On May 15, 2014, at 2:34 PM, Fabricio Cannini wrote:
Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) tho
On May 15, 2014, at 2:34 PM, Fabricio Cannini wrote:
> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
>> I think Ralph's email summed it up pretty well -- we unfortunately have (at
>> least) two distinct groups of people who install OMPI:
>>
>> a) those who know exactly what they want
On Thu, May 15, 2014 at 06:34:20PM -0300, Fabricio Cannini wrote:
> Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
> >I think Ralph's email summed it up pretty well -- we unfortunately have (at
> >least) two distinct groups of people who install OMPI:
> >
> >a) those who know exactly what
Please allow me to chip in my $0.02 and suggest to not reinvent the
wheel, but instead consider to migrate the build system to cmake :
http://www.cmake.org/
I agree that menu-wise, CMake does a pretty good job with ccmake, and is
much, much easier to create than autoconf/automake/m4 stuff (
Em 15-05-2014 07:29, Jeff Squyres (jsquyres) escreveu:
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what th
Hi Gus
The issue is that you have to work thru all the various components (leafing
thru the code base) to construct a list of all the things you *don't* want to
build. By default, we build *everything*, so there is no current method to
simply "build only what I want".
For those building static
Hi List
Sorry, but I confess I am having a hard time to understand
all the fuss about this.
At least in OMPI 1.6.5 there are already
two configure options that just knock out support for slurm and
loadleveler if they are set to "no", hopefully for the joy of everybody
that want lean and mean OMP
These are all good points -- thanks for the feedback.
Just to be clear: my point about the menu system was to generate file that
could be used for subsequent installs, very specifically targeted at those who
want/need scriptable installations.
One possible scenario could be: you download OMPI
I’m not sure how this would apply to other options, but for the scheduler, what
about no scheduler-related options defaults to everything enabled (like
before), but having any explicit scheduler enable option disables by default
all the other schedulers? Multiple explicit enable options would en
A file would do the trick, but from my experience of building programs,
I always prefer configure options. Maybe just an option
--disable-optional
that disables anything that is optional and non-explicitely requested.
Maxime
Le 2014-05-15 08:22, Bennet Fauber a écrit :
Would a separate file t
Would a separate file that contains each scheduler option and is
included by configure do the trick? It might read
include-slurm=YES
include-torque=YES
etc.
If all options are set to default to YES, then the people who want no
options are satisfied, but those of us who would like to change the
c
Le 2014-05-15 06:29, Jeff Squyres (jsquyres) a écrit :
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what th
I think Ralph's email summed it up pretty well -- we unfortunately have (at
least) two distinct groups of people who install OMPI:
a) those who know exactly what they want and don't want anything else
b) those who don't know exactly what they want and prefer to have everything
installed, and hav
I think Maxime's suggestion is sane and reasonable. Just in case
you're taking ha'penny's worth from the groundlings. I think I would
prefer not to have capability included that we won't use.
-- bennet
On Wed, May 14, 2014 at 7:43 PM, Maxime Boissonneault
wrote:
> For the scheduler issue, I
Good point - will see what we can do about it.
On May 14, 2014, at 4:43 PM, Maxime Boissonneault
wrote:
> For the scheduler issue, I would be happy with something like, if I ask for
> support for X, disable support for Y, Z and W. I am assuming that very rarely
> will someone use more than o
For the scheduler issue, I would be happy with something like, if I ask
for support for X, disable support for Y, Z and W. I am assuming that
very rarely will someone use more than one scheduler.
Maxime
Le 2014-05-14 19:09, Ralph Castain a écrit :
Jeff and I have talked about this and are app
Jeff and I have talked about this and are approaching a compromise. Still more
thinking to do, perhaps providing new configure options to "only build what I
ask for" and/or a tool to support a menu-driven selection of what to build - as
opposed to today's "build everything you don't tell me to
On May 14, 2014, at 3:21 PM, Jeff Squyres (jsquyres) wrote:
> On May 14, 2014, at 6:09 PM, Ralph Castain wrote:
>
>> FWIW: I believe we no longer build the slurm support by default, though I'd
>> have to check to be sure. The intent is definitely not to do so.
>
> The srun-based support buil
On May 14, 2014, at 6:09 PM, Ralph Castain wrote:
> FWIW: I believe we no longer build the slurm support by default, though I'd
> have to check to be sure. The intent is definitely not to do so.
The srun-based support builds by default. I like it that way. :-)
PMI-based support is a differen
Indeed, a quick review indicates that the new policy for scheduler support was
not uniformly applied. I'll update it.
To reiterate: we will only build support for a scheduler if the user
specifically requests it. We did this because we are increasingly seeing
distros include header support for
FWIW: I believe we no longer build the slurm support by default, though I'd
have to check to be sure. The intent is definitely not to do so.
The plan we adjusted to a while back was to *only* build support for schedulers
upon request. Can't swear that they are all correctly updated, but that was
Here's a bit of our rational, from the README file:
Note that for many of Open MPI's --with- options, Open MPI will,
by default, search for header files and/or libraries for . If
the relevant files are found, Open MPI will built support for ;
if they are not found, Open MPI will s
Hi Gus,
Oh, I know that, what I am refering to is that slurm and loadleveler
support are enabled by default, and it seems that if we're using
Torque/Moab, we have no use for slurm and loadleveler support.
My point is not that it is hard to compile it with torque support, my
point is that it i
On 05/14/2014 04:25 PM, Maxime Boissonneault wrote:
Hi,
I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
single scheduler has its support enabled by default at configure (except
the one I need, which is Torque). Is there a reason for that ? Why not
have a single scheduler
Hi,
I was compiling OpenMPI 1.8.1 today and I noticed that pretty much every
single scheduler has its support enabled by default at configure (except
the one I need, which is Torque). Is there a reason for that ? Why not
have a single scheduler enabled and require to specify it at configure
ti
41 matches
Mail list logo
