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 OMPI installations.
(Maybe those options are available in OMPI 1.8.1 also?
I haven't tried it.)
One could go on and on and make a comprehensive list of all options
that one wants in/out, and configure with/without all of them.
Isn't this level of simplicity, effectiveness, and of
standard use of configure options, good enough for us?
Works for me.
IMHO, what would help is to very clearly document
on the "configure --help" output what is the default value of
This would allow system administrators and other users to safely
make informed choices (or just let the defaults go, if they prefer).
Although I must say right now "configure --help" is not that bad at all.
I am not frustrated with it. It may need only a few tweaks.
Currently the --with-slurm and --with-loadleveler options
are clearly documented as having "yes" as the default.
However, other options don't have so clearly documented defaults.
In particular -with-tm Torque (which seems to depend on its libraries
and headers being found or not by configure).
By contrast --with-sge clearly says "no" is the default.
This covers pretty much all free/open source schedulers,
correct me if I am wrong, please.
LSF seems not to have a clearly documented default also.
But LSF is for the rich. I am out.
My 2 cents, 2nd edition, out of print.
Bye, thanks, regards.
On 05/15/2014 09:35 AM, Jeff Squyres (jsquyres) wrote:
> 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, run the menu installer so that you can see the options that are available, pick the ones you want, generate the file, and then use it in automated installs (e.g., ./configure --only-build-this-stuff=file_I_created_from_menu_installer).
> I am presuming that the generated file will be text, so it could be built/edited by hand, too. This is heavily inspired by the Linux kernel's "make menuconfig": it generates a .config file that you can use for subsequent builds.
> We can also look at the possibility of providing a template file that lists all options that are available in that particular tarball (similar to the Linux kernel "make config").
> This, BTW, is one part where we need to build some new infrastructure: to register and discover all available options (history has shown that just maintaining a text file for a project the size of Open MPI is not feasible -- it'll get stale/out of date).
> Other large projects do this kind of thing; we need to see if there's any ideas/code we can borrow rather than completely re-inventing the wheel.
> Again, these are just my thoughts after having thought about this for only about 30 minutes -- so this is likely quite rough and may not even resemble what we finally end up with.
> On May 15, 2014, at 8:51 AM, Noam Bernstein <noam.bernstein_at_[hidden]> wrote:
>> Im 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 enable all the requested schedulers, and disable everything else.
>> users mailing list