Add gcc dependency to make building easier?

[jchodera]

There is now a gcc conda package complete with fortran compiler that will make building simpler.

[kyleabeauchamp]

Bad idea, i had major difficulties having a parallel gcc installed via conda. On Apr 9, 2015 8:44 PM, "John Chodera" [email protected] wrote:

There is now a gcc conda package https://binstar.org/anaconda/gcc complete with fortran compiler that will make building simpler.

— Reply to this email directly or view it on GitHub https://github.com/choderalab/ambermini/issues/13.

[jchodera]

Ah, OK. The idea was just to require it at build time (where it is only transiently installed), since the alternative can mean that we need all sorts of compilers installed on the build system. I think everything gets statically linked anyway.

[swails]

I tend to agree with @kyleabeauchamp. I don't think the conda gcc has anything to offer over the one you get with a package manager. And I have yet to encounter a Linux distro where gfortran was harder to get than apt-get install gfortran (or gcc-fortran for SUSE, for example).

[kyleabeauchamp]

My particular problem was erratic build failures due to header incompatibility. I actually didnt even know I had conda gcc installed. Build time might be better, but Im not sure. On Apr 9, 2015 8:58 PM, "Jason Swails" [email protected] wrote:

I tend to agree with @kyleabeauchamp https://github.com/kyleabeauchamp. I don't think the conda gcc has anything to offer over the one you get with a package manager. And I have yet to encounter a Linux distro where gfortran was harder to get than apt-get install gfortran (or gcc-fortran for SUSE, for example).

— Reply to this email directly or view it on GitHub https://github.com/choderalab/ambermini/issues/13#issuecomment-91391807.

[jchodera]

@swails, I'm recommending using it only during the build phase, which would mean that it would never be delivered to your machine when you do conda install ..., but that the worker machines that build the tool wouldn't necessarily have to have all sorts of crazy fortran compilers installed.

Building the ambermini conda package on our cluster, for example, requires hacking the recipe to specify all sorts of local paths that get erased by the conda build environment since these paths are essential to making the module-installed fortran compilers work.

[kyleabeauchamp]

So one argument for not changing things is that we already engineered a pretty stable solution--use the jenkins virtual machine to build conda binary packages. AFAIK, we don't really need to rebuild ambermini on our cluster--we can just use conda install ambermini.

[swails]

It'll be easier if I can see what you mean by

hacking the recipe to specify all sorts of local paths that get erased by the conda build environment

I fail to see why ambermini is any more complicated than OpenMM when it comes to building conda packages. But I've never done it, so you would know better. (Perhaps you can help me to understand tomorrow.)

[jchodera]

@swails: Fortran?

@kyleabeauchamp: True, no need to change now, but it seems inconsistent with the "clean build environment" notion of conda packaging to rely on so much installed junk that has to be configured "just so" in order to even build packages. But we can live with it for now.

[swails]

@swails: Fortran?

How's that any different from C++? If you fire up a vanilla Linux distro (true for Fedora, Ubuntu, and OpenSUSE), you get no gfortran and no g++ (and on at least one of them, no gcc). Yet you can get gfortran on all distros just as easily as you can get g++ there.

Add in the CUDA and OpenCL requirements that go into the conda build and all of a sudden Fortran doesn't look so heavy... :)