This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
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
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/