Yoinks. Looks like this was an oversight. :-(
Yes, I agree that install_in_opt should put the modulefile in /opt as well.
If you could offer a patch or pull request, that would be awesome.
Thank you!
> On Mar 22, 2017, at 10:35 PM, Kevin Buckley
> <kevin.buckley.ecs.vuw.ac...@gmail.com> wrote:
>
> Just came to rehash some old attempts to build previous OpenMPIs
> for an RPM-based system and noticed that, despite specifying
>
> --define 'install_in_opt 1' \
>
> as part of this full "config" rpmbuild stage
>
> (Note: SPEC-file Release tag is atered so as not to have the RPM clash with
> any system MPI packages, hence the name change)
>
>
> rpmbuild \
> --define '_topdir /path/to/my/rpmbuild' \
> --define 'install_in_opt 1' \
> --define 'install_shell_scripts 1' \
> --define 'install_modulefile 1' \
> --define 'use_mpi_selector 0' \
> --define 'build_all_in_one_rpm 1' \
> -bb openmpi-2.0.2_vuw_gcc.spec
>
> I stll get a non /opt hierachy file
>
> /usr/share/Modules/modulefiles/openmpi/2.0.2
>
> which isn't what is needed.
>
> I'd have thought the module files for an "install_in_opt" configuration
> would have been installed below the
>
> /opt/openmpi/2.0.2/share
>
> tree, leaving the system admin to then place them wherever they needed
> to end up within the local "system dir" hierachies.
>
> (Note: I use /etc/modulefiles/ in addition to /usr/share/Modules/modulefiles/,
> which I consider to be the module files from the modules package itself)
>
>
>
> I note in the SPEC-file that there are possible overrides to any related
> defaults, vis:
>
> # type: string (root path to install modulefiles)
> %{!?modulefile_path: %define modulefile_path /usr/share/Modules/modulefiles}
> # type: string (subdir to install modulefile)
> %{!?modulefile_subdir: %define modulefile_subdir %{name}}
> # type: string (name of modulefile)
> %{!?modulefile_name: %define modulefile_name %{version}}
>
> but would suggest that the
>
> install_modulefile 1
>
> when combined with
>
> install_in_opt 1
>
> should alter the default, without any extra user configuration, just as if
> an AutoTools config had done a
>
> --prefix=/opt
>
> in which case everything would be expected to get the prefix .
>
>
> Just a suggestion, though I'll look to offer a patch, now that I see
> that my notes from 2012 about this (where I first found the issue!)
> still apply but, before I look to offer the patch ...
>
> whaddyathink of the suggestion itself?
>
>
> Kevin M. Buckley
>
> eScience Consultant
> School of Engineering and Computer Science
> Victoria University of Wellington
> New Zealand
> _______________________________________________
> devel mailing list
> devel@lists.open-mpi.org
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
--
Jeff Squyres
jsquy...@cisco.com
_______________________________________________
devel mailing list
devel@lists.open-mpi.org
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
