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 config would have an easy and scriptable way to change the option using sed or whatever. I agree with Maxime about requiring an interactive system to turn things off. It makes things difficult to script and document exactly what was done. I think providing the kitchen sink is fine for default, but a simple switch or config file that flips it to including nothing that wasn't requested might satisfy the other side. I suspect that something similar would (or could) be part of a menu configuration scheme, so the menu could be tacked on later, if it turns out to be desired, and the menu would just modify the list of things to build, so any work toward that scheme might not be lost. -- bennet On Thu, May 15, 2014 at 7:41 AM, Maxime Boissonneault <maxime.boissonnea...@calculquebec.ca> wrote: > 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 they want and prefer to have >> everything installed, and have OMPI auto-select at run time exactly what to >> use based on the system on which it's running >> >> We've traditionally catered to the b) crowd, and made some >> not-very-easy-to-use capabilities for the a) crowd (i.e., you can manually >> disable each plugin you don't want to build via configure, but the syntax is >> fairly laborious). >> >> Ralph and I talked about the possibility of something analogous to "make >> menuconfig" for Linux kernels, where you get a menu-like system (UI TBD) to >> pick exactly what options you want/don't want. That will output a text >> config file that can be fed to configure, something along the lines of >> >> ./configure --only-build-exactly-this-stuff=file-output-from-menuconfig >> >> This idea is *very* rough; I anticipate that it will change quite a bit >> over time, and it'll take us a bit of time to design and implement it. > > A menu-like system is not going to be very useful at least for us, since we > script all of our installations. Scripting a menu is not very handy. > > Maxime > > >> >> >> On May 14, 2014, at 8:56 PM, Bennet Fauber <ben...@umich.edu> wrote: >> >>> 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 >>> <maxime.boissonnea...@calculquebec.ca> 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 one scheduler. >>>> >>>> Maxime >>>> >>>> Le 2014-05-14 19:09, Ralph Castain a écrit : >>>>> >>>>> 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 >>>>> not-build" >>>>> >>>>> Tough set of compromises as it depends on the target audience. Sys >>>>> admins >>>>> prefer the "build only what I say", while users (who frequently aren't >>>>> that >>>>> familiar with the inners of a system) prefer the "build all" mentality. >>>>> >>>>> >>>>> On May 14, 2014, at 3:16 PM, Ralph Castain <r...@open-mpi.org> wrote: >>>>> >>>>>> 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 various schedulers, and so just >>>>>> finding >>>>>> the required headers isn't enough to know that the scheduler is >>>>>> intended for >>>>>> use. So we wind up building a bunch of useless modules. >>>>>> >>>>>> >>>>>> On May 14, 2014, at 3:09 PM, Ralph Castain <r...@open-mpi.org> 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 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 the intent. >>>>>>> >>>>>>> >>>>>>> On May 14, 2014, at 2:52 PM, Jeff Squyres (jsquyres) >>>>>>> <jsquy...@cisco.com> wrote: >>>>>>> >>>>>>>> Here's a bit of our rational, from the README file: >>>>>>>> >>>>>>>> Note that for many of Open MPI's --with-<foo> options, Open MPI >>>>>>>> will, >>>>>>>> by default, search for header files and/or libraries for <foo>. >>>>>>>> If >>>>>>>> the relevant files are found, Open MPI will built support for >>>>>>>> <foo>; >>>>>>>> if they are not found, Open MPI will skip building support for >>>>>>>> <foo>. >>>>>>>> However, if you specify --with-<foo> on the configure command line >>>>>>>> and >>>>>>>> Open MPI is unable to find relevant support for <foo>, configure >>>>>>>> will >>>>>>>> assume that it was unable to provide a feature that was >>>>>>>> specifically >>>>>>>> requested and will abort so that a human can resolve out the >>>>>>>> issue. >>>>>>>> >>>>>>>> In some cases, we don't need header or library files. For example, >>>>>>>> with SLURM and LSF, our native support is actually just >>>>>>>> fork/exec'ing the >>>>>>>> SLURM/LSF executables under the covers (e.g., as opposed to using >>>>>>>> rsh/ssh). >>>>>>>> So we can basically *always* build them. So we do. >>>>>>>> >>>>>>>> In general, OMPI builds support for everything that it can find on >>>>>>>> the >>>>>>>> rationale that a) we can't know ahead of time exactly what people >>>>>>>> want, and >>>>>>>> b) most people want to just "./configure && make -j 32 install" and >>>>>>>> be done >>>>>>>> with it -- so build as much as possible. >>>>>>>> >>>>>>>> >>>>>>>> On May 14, 2014, at 5:31 PM, Maxime Boissonneault >>>>>>>> <maxime.boissonnea...@calculquebec.ca> wrote: >>>>>>>> >>>>>>>>> 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 is compiling support for many schedulers while I'm >>>>>>>>> rather >>>>>>>>> convinced that very few sites actually use multiple schedulers at >>>>>>>>> the same >>>>>>>>> time. >>>>>>>>> >>>>>>>>> >>>>>>>>> Maxime >>>>>>>>> >>>>>>>>> Le 2014-05-14 16:51, Gus Correa a écrit : >>>>>>>>>> >>>>>>>>>> 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 enabled and require to specify it at >>>>>>>>>>> configure >>>>>>>>>>> time ? >>>>>>>>>>> >>>>>>>>>>> Is there any reason for me to build with loadlever or slurm if >>>>>>>>>>> we're >>>>>>>>>>> using torque ? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Maxime Boisssonneault >>>>>>>>>> >>>>>>>>>> Hi Maxime >>>>>>>>>> >>>>>>>>>> I haven't tried 1.8.1 yet. >>>>>>>>>> However, for all previous versions of OMPI I tried, up to 1.6.5, >>>>>>>>>> all it took to configure it with Torque support was to point >>>>>>>>>> configure >>>>>>>>>> to the Torque installation directory (which is non-standard in my >>>>>>>>>> case): >>>>>>>>>> >>>>>>>>>> --with-tm=/opt/torque/bla/bla >>>>>>>>>> >>>>>>>>>> My two cents, >>>>>>>>>> Gus Correa >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> users mailing list >>>>>>>>>> us...@open-mpi.org >>>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> --------------------------------- >>>>>>>>> Maxime Boissonneault >>>>>>>>> Analyste de calcul - Calcul Québec, Université Laval >>>>>>>>> Ph. D. en physique >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> users mailing list >>>>>>>>> us...@open-mpi.org >>>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Jeff Squyres >>>>>>>> jsquy...@cisco.com >>>>>>>> For corporate legal information go to: >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> users mailing list >>>>>>>> us...@open-mpi.org >>>>>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>>> >>>>> _______________________________________________ >>>>> users mailing list >>>>> us...@open-mpi.org >>>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>>> >>>> >>>> >>>> -- >>>> --------------------------------- >>>> Maxime Boissonneault >>>> Analyste de calcul - Calcul Québec, Université Laval >>>> Ph. D. en physique >>>> >>>> _______________________________________________ >>>> users mailing list >>>> us...@open-mpi.org >>>> http://www.open-mpi.org/mailman/listinfo.cgi/users >>> >>> _______________________________________________ >>> users mailing list >>> us...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/users >> >> > > > -- > --------------------------------- > Maxime Boissonneault > Analyste de calcul - Calcul Québec, Université Laval > Ph. D. en physique > > _______________________________________________ > users mailing list > us...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/users
