Re: [easybuild] PyPi legacy is gone.... and ideas on source_urls for Python extensions

[Kenneth Hoste]

Hi Jack,

On 11/07/2018 20:04, Jack Perdue wrote:

Howdy Kenneth,

For example, I'm trying to build IPython and as
a Bundle with extensions trying to fetch files from:

  https://files.pythonhosted.org/packages/source/i/ipython/

which doesn't exist.


That's not what I'm seeing with the just released EasyBuild v3.6.2 (this 
behavior hasn't changed compared to EasyBuild v3.6.1).


Here's a relevant bit from the EasyBuild log that shows it's downloading 
directly from https://pypi.python.org/packages (not via 
https://files.pythonhosted.org/packages).


== 2018-07-11 22:53:46,457 filetools.py:471 INFO Downloaded file 
ipython_urls.html from url https://pypi.python.org/simple/ipython to 
/Users/kehoste/work/TMP/eb-_E1vS6/tmppmy5pk/ipython_urls.html
== 2018-07-11 22:53:46,457 filetools.py:491 INFO Successful download of 
file ipython_urls.html from url https://pypi.python.org/simple/ipython 
to path /Users/kehoste/work/TMP/eb-_E1vS6/tmppmy5pk/ipython_urls.html
== 2018-07-11 22:53:51,753 filetools.py:471 INFO Downloaded file 
ipython-6.2.1.tar.gz from url 
https://pypi.python.org/packages/fa/50/974211502bd72873728d44c3013fe79875c819c8fb69f778bcfd67bc7d38/ipython-6.2.1.tar.gz 
to /tmp/i/IPython/extensions/ipython-6.2.1.tar.gz
== 2018-07-11 22:53:51,753 filetools.py:491 INFO Successful download of 
file ipython-6.2.1.tar.gz from url 
https://pypi.python.org/packages/fa/50/974211502bd72873728d44c3013fe79875c819c8fb69f778bcfd67bc7d38/ipython-6.2.1.tar.gz 
to path /tmp/i/IPython/extensions/ipython-6.2.1.tar.gz
== 2018-07-11 22:53:51,753 easyblock.py:730 INFO Successfully downloaded 
source file ipython-6.2.1.tar.gz from 
https://pypi.python.org/packages/fa/50/974211502bd72873728d44c3013fe79875c819c8fb69f778bcfd67bc7d38/ipython-6.2.1.tar.gz




See:

IPython-6.2.1-foss-2017a-Python-3.6.4.eb

(which is  IPython-6.4-foss-2017b-Python-3.6.3.eb here).

I saw some issues in framework covering problems
with the templates in extensions.  Should
I change all the hard-coded dirs for extensions
as just PYPI_SOURCE and let EB handle the rest?


PYPI_SOURCE probably isn't going to work with extensions...

But if you use source URLs like 
https://pypi.python.org/packages/source/i/ipython/, EasyBuild will 
automagically translate them to the correct hash URL via 
https://pypi.python.org/simple ...



regards,

Kenneth




Jack Perdue
Lead Systems Administrator
High Performance Research Computing
TAMU Division of Research
j-per...@tamu.edu    http://hprc.tamu.edu
HPRC Helpdesk: h...@hprc.tamu.edu

On 07/11/2018 12:50 PM, Kenneth Hoste wrote:

Hi Jack,

On 11/07/2018 01:38, Jack Perdue wrote:

As recently as a week or two ago, the "legacy"
PyPi site was still serving files from old source_urls.

That no longer seems to be the case.

And the new URLs seem to be a random mess.

Has anyone pondered how to deail with this?


EasyBuild has dealt with this for a while (since v2.8.0), by 
auto-translating PyPI URLs, see 
https://github.com/easybuilders/easybuild-framework/pull/1749 .


Are you saying that functionality is broken?

Seems to be working fine (we also check this in the framework test 
suite, of course):


$ python -c "from test.framework.utilities import init_config; from 
easybuild.tools.filetools import derive_alt_pypi_url; init_config(); 
print 
derive_alt_pypi_url('https://pypi.python.org/packages/source/e/easybuild/easybuild-2.7.0.tar.gz')" 



INFO: This is (based on) vsc.install.shared_setup 0.11.2
https://pypi.python.org/packages/5b/03/e135b19fadeb9b1ccb45eac9f60ca2dc3afe72d099f6bd84e03cb131f9bf/easybuild-2.7.0.tar.gz 




The source tarball can be downloaded using "curl -OL" just fine...


regards,

Kenneth

Re: [easybuild] Loading toolchain module and CC/CXX env vars

[Fotis Georgatos]

One more approach: most toolchains have a corresponding zlib build. We used to 
fish out its ./easybuild/*devel*.eb modulefile for manual builds and for not 
too complex builds it could help a lot. In effect, you need to shop from 
something that has the same deps as what you want build and same building 
conditions... (the mechanical way to derive that, might imply it is a kind of 
feature to have)

F.

Sent from my iPhone

On 11 Jul 2018, at 2:56 PM, Bart Oldeman 
mailto:bart.olde...@calculquebec.ca>> wrote:

Note that there is also a complimentary approach using --dump-env-script, e.g.:
$ eb --dump-env-script HPL-2.2-foss-2018b.eb
== temporary log file in case of crash 
/localscratch/eb-GygDhc/easybuild-HYqbH4.log
Script to set up build environment for HPL-2.2-foss-2018b.eb dumped to 
HPL-2.2-foss-2018b.env
== Temporary log file(s) /localscratch/eb-GygDhc/easybuild-HYqbH4.log* have 
been removed.
== Temporary directory /localscratch/eb-GygDhc has been removed.
$ source HPL-2.2-foss-2018b.env
$ echo $CC
mpicc

you can inspect the env script to see what is set. From time to time I do that 
when compilations are stuck: source the env script and then cd to the build 
folder which is still there after the compilation failed (we put it somewhere 
under /dev/shm for speed).

Just be aware that after sourcing this the shell session is essentially 
"throw-away" -- it is too polluted to do much else after.

Regards,
Bart

On Wed, 11 Jul 2018 at 08:03, Lars Viklund 
mailto:lars.vikl...@umu.se>> wrote:
I provide them for all sorts of toolchains, preparing them with 
`--try-toolchain` from one of the existing ones instead of upstreaming them.
They are very handy if you ever have end-user builds of software outside of EB.

// Lars Viklund

From: easybuild-requ...@lists.ugent.be 
mailto:easybuild-requ...@lists.ugent.be>> on 
behalf of Paul Melis mailto:paul.me...@surfsara.nl>>
Sent: Wednesday, July 11, 2018 13:39
To: easybuild@lists.ugent.be; Caspar van 
Leeuwen
Subject: Re: [easybuild] Loading toolchain module and CC/CXX env vars

On 11-07-18 13:27, Caspar van Leeuwen wrote:
 > Curious to hear what you (and others) think. Also, apart from Juelich,
 > are other institutes running into the same problems that we are, and is
 > are the buildenv blocks/configs also the way they solve it? For
 > uniformity and reusability of EasyBlocks/Configs I think it would be
 > good if 'we, the community' adopt a uniform solution for this issue.

Judging by the fact that there's only buildenv modules for three intel
toolchains (and none for e.g. foss) I guess these aren't actually used
that much and/or only in very specific circumstances?

Paul

--

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl | 
www.surfsara.nl |


--
Dr. Bart E. Oldeman | bart.olde...@mcgill.ca | 
bart.olde...@calculquebec.ca
Scientific Computing Analyst / Analyste en calcul scientifique
McGill HPC Centre / Centre de Calcul Haute Performance de McGill | 
http://www.hpc.mcgill.ca
Calcul Québec | http://www.calculquebec.ca
Compute/Calcul Canada | http://www.computecanada.ca
Tel/Tél: 514-396-8926 | Fax/Télécopieur: 514-396-8934

[easybuild] [ANN] EasyBuild v3.6.2

[Kenneth Hoste]

Dear EasyBuilders,

I'm happy to announce the release of EasyBuild version 3.6.2 [1].

And yes, once again, this is the best EasyBuild release since the dawn 
of time...


This is primarily a bugfix/update release.

Highlights include:

* support generating Docker container recipes & image via 
--containerize (still experimental)


* earlier check whether provided files are actually easyconfig files

* software-specific easyblock for OpenCV

* easyconfigs for new common toolchains: foss/2018b & intel/2018b 
(+ fosscuda/2018b)


* support for 28 new software packages, incl. FreeFem++, MAJIQ, 
Pytorch, ...


* updates for already supported software, incl. GROMACS 2018.2, 
HDF5 1.10.2, IPython 6.3.1, Kraken 1.0, Mesa 18.1.1, netCDF 4.6.1, 
NWChem 6.8, OpenBLAS 0.3.1, OpenMPI 3.1.1, Perl 5.28.0, Python 2.7.15, R 
3.5.0, X11 20180604


* various additional bug fixes, updates & enhancements

This brings the total number of supported software packages to 1,489!
An up-to-date list of supported software is available at [2].

A detailed overview of all changes is available in the release notes [3].

Thanks to everyone who contributed to this release in one way or another!


To upgrade to EasyBuild v3.6.2, there are several options [4].
Two particularly easy options include:

* eb --install-latest-eb-release
  # this requires EasyBuild v3.3.0 or more recent since support
for SHA256 checksums is required

* eb --from-pr 6578   # use easyconfig from PR #6578 [5]


Enjoy!

regards,

Kenneth (a.k.a. boegel)
EasyBuild release manager


[1] https://pypi.org/project/easybuild/3.6.2
[2] 
http://easybuild.readthedocs.io/en/latest/version-specific/Supported_software.html

[3] http://easybuild.readthedocs.io/en/latest/Release_notes.html
[4] 
http://easybuild.readthedocs.io/en/latest/Installation.html#updating-an-existing-easybuild-installation

[5] https://github.com/easybuilders/easybuild-easyconfigs/pull/6578/files

Re: [easybuild] PyPi legacy is gone.... and ideas on source_urls for Python extensions

[Jack Perdue]

Howdy Kenneth,

For example, I'm trying to build IPython and as
a Bundle with extensions trying to fetch files from:

 https://files.pythonhosted.org/packages/source/i/ipython/

which doesn't exist.

See:

IPython-6.2.1-foss-2017a-Python-3.6.4.eb

(which is  IPython-6.4-foss-2017b-Python-3.6.3.eb here).

I saw some issues in framework covering problems
with the templates in extensions.  Should
I change all the hard-coded dirs for extensions
as just PYPI_SOURCE and let EB handle the rest?


Jack Perdue
Lead Systems Administrator
High Performance Research Computing
TAMU Division of Research
j-per...@tamu.eduhttp://hprc.tamu.edu
HPRC Helpdesk: h...@hprc.tamu.edu

On 07/11/2018 12:50 PM, Kenneth Hoste wrote:

Hi Jack,

On 11/07/2018 01:38, Jack Perdue wrote:

As recently as a week or two ago, the "legacy"
PyPi site was still serving files from old source_urls.

That no longer seems to be the case.

And the new URLs seem to be a random mess.

Has anyone pondered how to deail with this?


EasyBuild has dealt with this for a while (since v2.8.0), by 
auto-translating PyPI URLs, see 
https://github.com/easybuilders/easybuild-framework/pull/1749 .


Are you saying that functionality is broken?

Seems to be working fine (we also check this in the framework test 
suite, of course):


$ python -c "from test.framework.utilities import init_config; from 
easybuild.tools.filetools import derive_alt_pypi_url; init_config(); 
print 
derive_alt_pypi_url('https://pypi.python.org/packages/source/e/easybuild/easybuild-2.7.0.tar.gz')"


INFO: This is (based on) vsc.install.shared_setup 0.11.2
https://pypi.python.org/packages/5b/03/e135b19fadeb9b1ccb45eac9f60ca2dc3afe72d099f6bd84e03cb131f9bf/easybuild-2.7.0.tar.gz 




The source tarball can be downloaded using "curl -OL" just fine...


regards,

Kenneth

Re: [easybuild] PyPi legacy is gone.... and ideas on source_urls for Python extensions

[Kenneth Hoste]

Hi Jack,

On 11/07/2018 01:38, Jack Perdue wrote:

As recently as a week or two ago, the "legacy"
PyPi site was still serving files from old source_urls.

That no longer seems to be the case.

And the new URLs seem to be a random mess.

Has anyone pondered how to deail with this?


EasyBuild has dealt with this for a while (since v2.8.0), by 
auto-translating PyPI URLs, see 
https://github.com/easybuilders/easybuild-framework/pull/1749 .


Are you saying that functionality is broken?

Seems to be working fine (we also check this in the framework test 
suite, of course):


$ python -c "from test.framework.utilities import init_config; from 
easybuild.tools.filetools import derive_alt_pypi_url; init_config(); 
print 
derive_alt_pypi_url('https://pypi.python.org/packages/source/e/easybuild/easybuild-2.7.0.tar.gz')"


INFO: This is (based on) vsc.install.shared_setup 0.11.2
https://pypi.python.org/packages/5b/03/e135b19fadeb9b1ccb45eac9f60ca2dc3afe72d099f6bd84e03cb131f9bf/easybuild-2.7.0.tar.gz


The source tarball can be downloaded using "curl -OL" just fine...


regards,

Kenneth

Re: [easybuild] Next EasyBuild conf call: Wed July 11th 2018, 5pm CEST

[Vanzo, Davide]

Dear EasyBuilders,

If you missed today's conf call, here you can find some notes:
https://github.com/easybuilders/easybuild/wiki/Conference-call-notes-20180711

The next conf call is scheduled for Wed July 25th 2018, see
https://plus.google.com/events/cpq2nqo8spt1u9uemvjkhgat9t8

Best regards

--
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.vanderbilt.edu/accre


On 2018-07-10 10:31:42-05:00 easybuild-requ...@lists.ugent.be wrote:

Dear EasyBuilders,

The next EasyBuild conf call is planned for tomorrow, Wed July 11th 2018, at 
5pm CEST, see also
https://plus.google.com/events/ctbcs6ocbe2gq8f55kslbqfs87g<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplus.google.com%2Fevents%2Fctbcs6ocbe2gq8f55kslbqfs87g=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C0abcee32a6a74ea6ee8608d5e67a3b44%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C0%7C636668335012660056=DXFQLpvmlteri7%2ByDQTVp4ZoWAAG%2BQk75MlJxTYwzfo%3D=0>

Current agenda:
* Upcoming EasyBuild 3.6.2 release
* Q
As usual, suggestions for additional topics are welcome.
More information on the EasyBuild conf calls is available at
https://github.com/easybuilders/easybuild/wiki/Conference-calls<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Feasybuilders%2Feasybuild%2Fwiki%2FConference-calls=02%7C01%7Cdavide.vanzo%40vanderbilt.edu%7C0abcee32a6a74ea6ee8608d5e67a3b44%7Cba5a7f39e3be4ab3b45067fa80faecad%7C0%7C1%7C636668335012670065=69XXWfQChwOvCIPZ6SCIk5p5lodcyeI%2FfKZWcIa2OTo%3D=0>

--
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.vanderbilt.edu/accre

Re: [easybuild] Loading toolchain module and CC/CXX env vars

[Bart Oldeman]

Note that there is also a complimentary approach using --dump-env-script,
e.g.:
$ eb --dump-env-script HPL-2.2-foss-2018b.eb
== temporary log file in case of crash
/localscratch/eb-GygDhc/easybuild-HYqbH4.log
Script to set up build environment for HPL-2.2-foss-2018b.eb dumped to
HPL-2.2-foss-2018b.env
== Temporary log file(s) /localscratch/eb-GygDhc/easybuild-HYqbH4.log* have
been removed.
== Temporary directory /localscratch/eb-GygDhc has been removed.
$ source HPL-2.2-foss-2018b.env
$ echo $CC
mpicc

you can inspect the env script to see what is set. From time to time I do
that when compilations are stuck: source the env script and then cd to the
build folder which is still there after the compilation failed (we put it
somewhere under /dev/shm for speed).

Just be aware that after sourcing this the shell session is essentially
"throw-away" -- it is too polluted to do much else after.

Regards,
Bart

On Wed, 11 Jul 2018 at 08:03, Lars Viklund  wrote:

> I provide them for all sorts of toolchains, preparing them with
> `--try-toolchain` from one of the existing ones instead of upstreaming them.
> They are very handy if you ever have end-user builds of software outside
> of EB.
>
> // Lars Viklund
> 
> From: easybuild-requ...@lists.ugent.be 
> on behalf of Paul Melis 
> Sent: Wednesday, July 11, 2018 13:39
> To: easybuild@lists.ugent.be; Caspar van Leeuwen
> Subject: Re: [easybuild] Loading toolchain module and CC/CXX env vars
>
> On 11-07-18 13:27, Caspar van Leeuwen wrote:
>  > Curious to hear what you (and others) think. Also, apart from Juelich,
>  > are other institutes running into the same problems that we are, and is
>  > are the buildenv blocks/configs also the way they solve it? For
>  > uniformity and reusability of EasyBlocks/Configs I think it would be
>  > good if 'we, the community' adopt a uniform solution for this issue.
>
> Judging by the fact that there's only buildenv modules for three intel
> toolchains (and none for e.g. foss) I guess these aren't actually used
> that much and/or only in very specific circumstances?
>
> Paul
>
> --
>
> Paul Melis
> | Visualization group leader & developer | SURFsara |
> | Science Park 140 | 1098 XG Amsterdam |
> | T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl |
>


-- 
Dr. Bart E. Oldeman | bart.olde...@mcgill.ca | bart.olde...@calculquebec.ca
Scientific Computing Analyst / Analyste en calcul scientifique
McGill HPC Centre / Centre de Calcul Haute Performance de McGill |
http://www.hpc.mcgill.ca
Calcul Québec | http://www.calculquebec.ca
Compute/Calcul Canada | http://www.computecanada.ca
Tel/Tél: 514-396-8926 | Fax/Télécopieur: 514-396-8934

Re: [easybuild] Loading toolchain module and CC/CXX env vars

[Lars Viklund]

I provide them for all sorts of toolchains, preparing them with 
`--try-toolchain` from one of the existing ones instead of upstreaming them.
They are very handy if you ever have end-user builds of software outside of EB.

// Lars Viklund

From: easybuild-requ...@lists.ugent.be  on 
behalf of Paul Melis 
Sent: Wednesday, July 11, 2018 13:39
To: easybuild@lists.ugent.be; Caspar van Leeuwen
Subject: Re: [easybuild] Loading toolchain module and CC/CXX env vars

On 11-07-18 13:27, Caspar van Leeuwen wrote:
 > Curious to hear what you (and others) think. Also, apart from Juelich,
 > are other institutes running into the same problems that we are, and is
 > are the buildenv blocks/configs also the way they solve it? For
 > uniformity and reusability of EasyBlocks/Configs I think it would be
 > good if 'we, the community' adopt a uniform solution for this issue.

Judging by the fact that there's only buildenv modules for three intel
toolchains (and none for e.g. foss) I guess these aren't actually used
that much and/or only in very specific circumstances?

Paul

--

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl |

Re: [easybuild] Loading toolchain module and CC/CXX env vars

[Alan O'Cais]

Hi Caspar

On Wed, 11 Jul 2018 at 13:27, Caspar van Leeuwen <
caspar.vanleeu...@surfsara.nl> wrote:

> Hi Alan,
>
> Thanks, I wasn't aware of the buildenv EasyBlock either, but it seems this
> may solve some problems I encountered in the past with compilers or flags
> that were not always correctly picked up by CMake. In the past, I sometimes
> passed these manually in the EasyConfigs, but that's a bit ugly. So, do I
> understand correctly that you load the buildenv EasyConfigs whenever you
> build new software through EasyBuild? Do you then add it as a build
> dependency to your existing EasyConfigs (which involves customizing
> existing EasyConfigs), or do you simply load the module before you run your
> 'eb some_easyconfig.eb'?
>

No, I only created this as a way to help give our users a working build
environment that reflects the EB toolchains (at least for an Autotools
scenario), it's not related to our EB setup at all.  It's quite limited in
that sense, you get a lot more useful information from `eb -x `
but of course that changes from config to config


>
> And another question: if I need to load these modules to get CMake to do
> what I intend, what if a user uses e.g. the foss toolchain to build some of
> his own software that relies on CMake? Do you instruct your users to load
> the buildenv module in those cases?
>

We tell them it's there but it's hard to know if any of them use it at all
(we don't keep track of module loads). Specifically with CMake, the
easyblock sets a few additional variables

so even buildenv won't give you everything you probably need.


>
> Finally, it makes me wonder if this (i.e. loading a compiler toolchain +
> seperate buildenv module) is the right design. To me, it seems very
> counterintuitive that loading the toolchain itself is not sufficient to
> have e.g. CMake pick up the correct compilers. Of course, toolchains are
> mostly loaded as dependencies for running production codes, in which case
> setting these variables would be unnecessary pollution of the environment.
> But other than that: is there any reason why the toolchains modules
> themselves don't set these build environments by default? (Kenneth, was
> this a conscious design decision, or did it just 'grow' like this?)
>

See above and the `-x` option, all these variables are indeed set, all
buildenv does is make it so that the user can set them in their own
environment.


>
> Curious to hear what you (and others) think. Also, apart from Juelich, are
> other institutes running into the same problems that we are, and is are the
> buildenv blocks/configs also the way they solve it? For uniformity and
> reusability of EasyBlocks/Configs I think it would be good if 'we, the
> community' adopt a uniform solution for this issue.
>
> Cheers,
>
> Caspar
>
>
> --
> *From: *"Alan O'Cais" 
> *To: *"easybuild" 
> *Sent: *Tuesday, 10 July, 2018 16:02:44
> *Subject: *Re: [easybuild] Loading toolchain module and CC/CXX env vars
>
> Hi Paul,
>
> There's a simple easyblock that implments this (for the toolchain):
>
> https://github.com/easybuilders/easybuild-easyblocks/blob/master/easybuild/easyblocks/generic/buildenv.py
> You can see example uses in
>
> https://github.com/easybuilders/easybuild-easyconfigs/tree/develop/easybuild/easyconfigs/b/buildenv
>
> Alan
>
> On Tue, 10 Jul 2018 at 15:56, Paul Melis  wrote:
>
>> Hi,
>>
>> When developing software (in contrast to simply building and installing
>> it with EB) it makes sense to leverage the existing toolchains for
>> setting up a build environment. E.g. I load foss/2017b and other needed
>> EB-built dependencies while developing and use CMake to build by hand.
>> When the package gets to a stable point creating an EB config is then
>> (relatively) easy and predictable, based on the loaded modules used.
>> Rebuilding by hand is also a lot quicker than doing a full EB build and
>> install each time.
>>
>> But loading a toolchain like foss/2017b doesn't completely set up the
>> environment in a way that makes it directly usable by CMake and friends.
>> Particularly, CC and CXX are not set so it's up to the build tool to
>> figure out which compiler to use.
>>
>> CMake does this somewhat silly in that it searches for (in order) cc,
>> gcc, cl, bcc, ... when CC is not set (and similarly c++, g++, aCC, cl,
>> ... when CXX is not set). But this is a breadth-first search of "cc" in
>> a set of directories. So in our case it actually finds /usr/bin/cc (and
>> /usr/bin/c++ next to it) which are old, GCC 4.8.5, and it doesn't find
>> the foss/2017b binaries. This appears to be because GCC installations
>> don't contain the "cc" command (even though they have a "c++" one),
>> which is what CMake searches for first.
>>
>> Setting CC and CXX to the foss/2017b compilers will fix this, which kind
>> of makes me wonder why these aren't set by 

Re: [easybuild] Loading toolchain module and CC/CXX env vars

[Paul Melis]

On 11-07-18 13:27, Caspar van Leeuwen wrote:
> Curious to hear what you (and others) think. Also, apart from Juelich,
> are other institutes running into the same problems that we are, and is
> are the buildenv blocks/configs also the way they solve it? For
> uniformity and reusability of EasyBlocks/Configs I think it would be
> good if 'we, the community' adopt a uniform solution for this issue.

Judging by the fact that there's only buildenv modules for three intel 
toolchains (and none for e.g. foss) I guess these aren't actually used 
that much and/or only in very specific circumstances?


Paul

--

Paul Melis
| Visualization group leader & developer | SURFsara |
| Science Park 140 | 1098 XG Amsterdam |
| T 020 800 1312 | paul.me...@surfsara.nl | www.surfsara.nl |