Re: [easybuild] Intel Parallel Studio components naming convention

2016-11-04 Thread Vanzo, Davide
Ole,
I think that this is more a docs issue than the specific easyconfig files. Also 
because it applies to any software that requires a license.
I will fork the docs repo, add the info and generate a PR.

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu

On Nov 4 2016, at 2:21 am, Ole Holm Nielsen  wrote:

Hi Davide,

When you update EB files, could you kindly add an explanation of the
variable INTEL_LICENSE_FILE in each EB file, given the fact that it
doesn't seems to be documented elsewhere and everybody will need to
customize it?

My suggestion of text for adding to all Intel EB files:

# Intel license_file must be specified. Select a long-term valid name.
# Can be overridden by setting the environment variable
# INTEL_LICENSE_FILE before running eb.
# Absolute path example:
# license_file = HOME + '/licenses/intel/license.lic'
# License server example:
# license_file = port-number@license-server

On 11/03/2016 11:10 PM, Vanzo, Davide wrote:
> as you have probably seen I am updating the easybuild files for the new
> Intel Parallel Studio XE 2017 Update 1.
> I started working on the other tools in the suite other than the main
> ones (compilers, MPI and MKL) and I am facing a naming dilemma. All main
> components easyconfigs use versioning in the 2017.1 form. That is great
> because it allows me to use version_major and version_minor to generate
> the source tarball name. The additional components instead use the
> "update1" version naming which brakes consistency across the whole
> suite. What would you think about adopting a uniform naming convention
> across the whole suite (and maybe also for the toolchains that use a
> preceding zero to the minor version number)?

Thanks,
Ole


Re: [easybuild] Intel Parallel Studio components naming convention

2016-11-04 Thread Ole Holm Nielsen

Hi Davide,

When you update EB files, could you kindly add an explanation of the 
variable INTEL_LICENSE_FILE in each EB file, given the fact that it 
doesn't seems to be documented elsewhere and everybody will need to 
customize it?


My suggestion of text for adding to all Intel EB files:

# Intel license_file must be specified.  Select a long-term valid name.
# Can be overridden by setting the environment variable
# INTEL_LICENSE_FILE before running eb.
# Absolute path example:
# license_file = HOME + '/licenses/intel/license.lic'
# License server example:
# license_file = port-number@license-server

On 11/03/2016 11:10 PM, Vanzo, Davide wrote:

as you have probably seen I am updating the easybuild files for the new
Intel Parallel Studio XE 2017 Update 1.
I started working on the other tools in the suite other than the main
ones (compilers, MPI and MKL) and I am facing a naming dilemma. All main
components easyconfigs use versioning in the 2017.1 form. That is great
because it allows me to use version_major and version_minor to generate
the source tarball name. The additional components instead use the
"update1" version naming which brakes consistency across the whole
suite. What would you think about adopting a uniform naming convention
across the whole suite (and maybe also for the toolchains that use a
preceding zero to the minor version number)?


Thanks,
Ole


[easybuild] Intel Parallel Studio components naming convention

2016-11-03 Thread Vanzo, Davide
Hello,
as you have probably seen I am updating the easybuild files for the new Intel 
Parallel Studio XE 2017 Update 1.
I started working on the other tools in the suite other than the main ones 
(compilers, MPI and MKL) and I am facing a naming dilemma. All main components 
easyconfigs use versioning in the 2017.1 form. That is great because it allows 
me to use version_major and version_minor to generate the source tarball name. 
The additional components instead use the "update1" version naming which brakes 
consistency across the whole suite. What would you think about adopting a 
uniform naming convention across the whole suite (and maybe also for the 
toolchains that use a preceding zero to the minor version number)?

--
Davide Vanzo, PhD
Application Developer
Adjunct Assistant Professor of Chemical and Biomolecular Engineering
Advanced Computing Center for Research and Education (ACCRE)
Vanderbilt University - Hill Center 201
(615)-875-9137
www.accre.vanderbilt.edu