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

Reply via email to