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, for example, this results in a much larger binary than really necessary. Those wanting a minimal build to avoid confusion (e.g., "why do i show slurm when I'm running moab?") face a similar issue. What we agree on is the need to provide the "build only what I want" capability. What Maxime has proposed is one way of doing that for at least the schedulers. Jeff and I are discussing additional options. On May 15, 2014, at 10:59 AM, Gus Correa <g...@ldeo.columbia.edu> wrote: > 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 OMPI installations. > (Maybe those options are available in OMPI 1.8.1 also? > I haven't tried it.) > > Just configure: > > --with-slurm=no --with-loadleveler=no > > 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 > *all* options. > > 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. > Gus Correa > > > 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.bernst...@nrl.navy.mil> >> wrote: >> >>> 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 >>> enable all the requested schedulers, and disable everything else. >>> >>> >>> Noam >>> _______________________________________________ >>> 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
