ncarg: fails to build out of the box and on build box

[petrrr]

Currently ncarg would not build out of the box and fails on the buildbots as well, due to conflicting variant requirements or lack of propagation of this requirement.

On a clean install, cleaned down to hdf5 (included), I get the following error message:

Error: Install hdf5 +gcc5
Error: org.macports.fetch for port ncarg returned: hdf5 +gcc5 not installed
Warning: targets not executed for ncarg: org.macports.activate org.macports.fetch org.macports.checksum org.macports.extract org.macports.patch org.macports.configure org.macports.build org.macports.destroot org.macports.install
Please see the log file for port ncarg for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_science_ncarg/ncarg/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port ncarg failed

The reason for this is that ncarg's dependencies -- notably hdfeos5 wgrib2 vis5d and esmf -- tight in hdf5, which however is installed by default without +gcc5 variant, while ncarg itself requires this variant.

This is what I get after the failure. hdf5 was newly installed w/o the +hdf5 variant:

hdf5 @1.8.16_2+cxx+hl

Here the ports which cause to install it, so hdf5 is not tight in directly by ncarg, but through its dependencies:

% port rdependents hdf5 # after the failure
The following ports are dependent on hdf5:
  hdfeos5
  netcdf
    netcdf-fortran
      esmf
    vis5d
    wgrib2

Why this variant is required by ncarg in the first place? Would it be an option set the default of hdf5 to this variant as well, to minimize the probability of conflicts? Otherwise, would it be an option to propagate the +gcc5 variant down the chain of dependencies?

[mamoll (Mark Moll)]

If hdf5 wasn't installed before you attempted to install ncarg, then sudo port install ncarg +gcc5 would pass on the +gcc5 variant to hdf5. Is this not happening?

[petrrr]

Negative! Or maybe ncarg +gcc5 might try effectively try to install hdf5 +gcc5, but at that time hdf5 was already installed throgh the other dependencies, see above (port rdependents hdf5 after the failure).

[petrrr]

These in principal have a +gcc5 variant:

• hdfeos5
• wgrib2
• esmf

But vis5d does not;

[petrrr]

Basically it seems that hdf5 is installed through the dependency chain

esmf +accelerate+gcc5
  -> netcdf-fortran +gcc5 
    -> netcdf +dap+netcdf4 
      -> `hdf5 +cxx+hl

[tenomoto (Takeshi Enomoto)]

I am aware the build bot failures and the need for manual install of hdf5 +gcc5. How can I fix this? Previously I didn't set dependency to hdf5 because of indirect to hdf5 through netcdf. But I added the dependency to hdf5 +gcc5 because I need to set the dependency to all the binaries and libraries are linked as far as I understand.

[gnw3]

For El Capitan (10.11.3, Xcode 7.2.1) netcdf +gcc5 is broken: ncdump from netcdf +gcc5 gives signal 11 on simple NetCDF4-CF files, but works reliably on 10.6.8 and 10.9.5.

[petrrr]

gnwiii@: It looks like your problem is somewhat unrelated to issue of this ticket. I therefore would propose to move it into a different ticket, to keep the discussion separated. Would you mind filing a new ticket, with all relevant details.

[tenomoto (Takeshi Enomoto)]

I close the ticket for now. Continuing the problem with netcdf +gcc5 in #50911.

[petrrr]

Why this ticket has been closed? The problem with dependencies not being correctly resolved should be still present. Or has there been a fix I am not aware of?

[tenomoto (Takeshi Enomoto)]

If there is a solution to the problem on dependency I'd like to know. I'd thought that the installation is (regrettably) manual if enforce_variant is set.

[petrrr]

I understand, that when hdf5 would already be installed with a different set of variants a manual resolution of the conflict is necessary. However, I have intentionally removed everything down to hdf5, and in this case the +gcc5 variant should be propagated down.

[tenomoto (Takeshi Enomoto)]

Yes, that what I'd expect. But it does not happen. I will try to find out the problem in the chain in your comment 5.

[tenomoto (Takeshi Enomoto)]

It appears that manually specified variants are proliferated but not those in default_variants.

[tenomoto (Takeshi Enomoto)]

I suggested to treat default_variants as same as manually set variants and we had a lengthy discussion, but I don't think we agree to fix the behaviour. So I decoupled ncarg from hdf5(-18) and removed mpi.enforce_variant in r148018. ncarg does not contain any MPI source and does not depend on hdf5(-18). I use h5cc and h5pcc for convenience; this is what this port used to be. OpenMP code is not used when the default C compiler system clang is used but I believe it is less important than the build error and a lack of a binary package; it seems that OpenMP was not effective according to ​this abstract. In addition I replaced reinplace with patches where possible.