On 11/12/2017 16:30, Erik Smeets wrote:
Hi,
There are also a lot of dependencies to applications that in my
opinion don't need a specific toolchain, but just need to be
available. Maybe don't add these to a specific toolchain or version,
but a generally avaible toolchain (dummy?).
There's a strong argument against using the 'dummy' toolchain more
often: when you do, you're at the mercy of the OS, in particular the
compiler/binutils provided by the OS. An easyconfig file that builds
without problems on your system, may not work for somebody else because
their OS has an older or more recent version of GCC.
Also, now dependencies are really strict on version, while this is not
always necessary. Maybe having something like '>' and/or '<' for
version dependencies might help to focus on applications that really
need updating.
Maybe this is already discussed and decided on a long time ago or
maybe this will cause other problems.
It has been discussed before (as Alan already mentioned), see
https://github.com/easybuilders/easybuild-framework/issues/746, but it
never materialized.
Also, I think it's a potential (large) can of worms. Making dependency
version specifications more flexible is definitely doable, but then how
loose do we allow version specs to be (in the central easyconfigs
repository, what sites do in their own easyconfigs is up to them, of
course).
Let me use CMake (ugh... :P) as an example: we now specify CMake as a
build dependency strictly (e.g. CMake==3.9.5).
If we loosen that up, what's acceptable?
CMake >= 3.9.5 -> what if CMake 4.0 is released, will it still work?)
CMake == 3.9.* -> is that flexible enough? surely 3.10 would also
work... but maybe 3.8 (or 3.2) won't?
CMake == 3.* -> any CMake 3.x works? did we test all of them?
You can probably come up with a potential problem for pretty much any
version range you use.
The strict versioning scheme now is both a blessing and a curse: it's a
way of communicating that a particular combinations of versions worked,
but it does result in unwanted side-effects (e.g. N different versions
of CMake installed, even for a single toolchain).
Getting less strict version specifications correct is *a lot* more work,
regardless of the requirement implementation in the EasyBuild framework
to support it.
That being said: I'm certainly not opposing this, but once someone
implements this ;-) we will need to be careful how we use it, to avoid
shooting ourselves in the foot.
regards,
Kenneth
Regards,
Erik
On Fri, Nov 24, 2017 at 10:48 AM, Åke Sandgren
<ake.sandg...@hpc2n.umu.se <mailto:ake.sandg...@hpc2n.umu.se>> wrote:
It's fairly simple.
Use whatever is already available for the selected toolchain. Don't
forget to check the git develop branch and any pending PRs when
deciding
on versions.
On 11/24/2017 10:16 AM, Joachim Hein wrote:
> Hi,
>
> Because of interoperability of software, I see an increasing
need to fix software versions beyond what is included in the
actual toolchains. I am discussing standard dependencies, like
jpeg libraries, HDF5, netcdf, curl. So, unless there is strong
reasons (e.g. bugs), packages build with a certain toolchain (e.g.
foss/2017a) should use a “preferred version” for standard
dependencies. Using the latest and greatest, which is what I did
some time ago has downsides in the form of module load conflicts.
>
> The question is how would one administer this (selection of
version(s), communication between contributors, …), without
driving the administrative burden even higher. I like to put this
for discussion among the regular contributors.
>
> Best wishes
> Joachim
>
--
Ake Sandgren, HPC2N, Umea University, S-90187 Umea, Sweden
Internet: a...@hpc2n.umu.se <mailto:a...@hpc2n.umu.se> Phone: +46
90 7866134 <tel:%2B46%2090%207866134> Fax: +46 90-580 14
<tel:%2B46%2090-580%2014>
Mobile: +46 70 7716134 <tel:%2B46%2070%207716134> WWW:
http://www.hpc2n.umu.se
