Alternate Install structure that allows for a simple CMAKE_PREFIX_PATH setting

[mark-a-potts]

The instruction how to build, for example UFS_UTILS, in the last paragraph:

_To use these libraries in applications such as UFSUTILS:

cmake -DCMAKE_PREFIX_PATH=/path/to/nceplibs-install ..

does not work, because libraries are installed as:

./nceplibs-install
├── bacio
│   ├── bacio-1.2.0
│   └── bacio-2.0.4
└── nemsio
    ├── nemsio-2.3.0
    └── nemsio-develop

instead of:

./nceplibs-install
├── bacio-1.2.0
├── bacio-2.0.4
├── nemsio-2.3.0
└── nemsio-develop

This basically means that the location of each library must be provided by <libname>_ROOT probably using environment modules, which is fine on HPC systems but very inconvenient on personal workstations (or in containers), where managing modules is additional (and unnecessary) complication.

What is the real advantage of the first vs the second install tree directory structure.

Originally posted by @DusanJovic-NOAA in https://github.com/NOAA-EMC/NCEPLIBS/pull/76#issuecomment-647122361

[mark-a-potts]

I am a little late to this discussion, but I agree with Dusan that the new directory structure is much less desirable for installs on non-NOAA/NCAR systems. I think it should be fairly simple to provide an alternate/optional install structure that would allow for the use of a single CMAKE_PREFIX_PATH for users who are building only a single version of NCEPLIBS.

[kgerheiser]

I do like the convenience of being able to set CMAKE_PREFIX_PATH for a quick and dirty build.

Maybe when -DDEPLOY=ON it's installed in the hierarchical structure and when it's not it's installed in the flat structure?

I agree that it's better to be explicit than implicit by using <package>_ROOT instead of a blanket CMAKE_PREFIX_PATH, because it could lead to confusing behavior, but when you have 15 libraries, and only the one version of them and you want to use them, it becomes unwieldy to specify 15 nearly identical paths on the command line.

Elsewhere we have modules for dealing with that.

[aerorahul]

I am a little late to this discussion, but I agree with Dusan that the new directory structure is much less desirable for installs on non-NOAA/NCAR systems. I think it should be fairly simple to provide an alternate/optional install structure that would allow for the use of a single CMAKE_PREFIX_PATH for users who are building only a single version of NCEPLIBS.

@mark-a-potts This was extensively discussed here

[aerorahul]

@mark-a-potts @kgerheiser If DEPLOY is OFF, one can make an assumption that modulefiles are not desired and paths are flat. Is that a good compromise?

[aerorahul]

gaah, I just read the comment from @kgerheiser

[mark-a-potts]

Yes, I realize that, and apologize for not chiming in earlier. I can certainly see the advantage to the new directory structure for sys-admins and overall maintenance. I like the DEPLOY compromise suggested by both Kyle and Rahul.

-M

On 6/23/20 1:03 PM, Rahul Mahajan wrote:

I am a little late to this discussion, but I agree with Dusan that
the new directory structure is much less desirable for installs on
non-NOAA/NCAR systems. I think it should be fairly simple to
provide an alternate/optional install structure that would allow
for the use of a single CMAKE_PREFIX_PATH for users who are
building only a single version of NCEPLIBS.

@mark-a-potts https://github.com/mark-a-potts This was extensively discussed here https://github.com/NOAA-EMC/NCEPLIBS/pull/76#issuecomment-647178700

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/NOAA-EMC/NCEPLIBS/issues/79#issuecomment-648292566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH4Q2USVE5H2JNGBNV4LP6LRYDN7RANCNFSM4OF2UCAQ.

[DusanJovic-NOAA]

I do like the convenience of being able to set CMAKE_PREFIX_PATH for a quick and dirty build.

Maybe when -DDEPLOY=ON it's installed in the hierarchical structure and when it's not it's installed in the flat structure?

I agree that it's better to be explicit than implicit by using <package>_ROOT instead of a blanket CMAKE_PREFIX_PATH, because it could lead to confusing behavior, but when you have 15 libraries, and only the one version of them and you want to use them, it becomes unwieldy to specify 15 nearly identical paths on the command line.

Elsewhere we have modules for dealing with that.

In simple-ufs I ended up with:

  for lib in bacio g2 gfsio ip landsfcutil nemsio nemsiogfs sfcio sigio sp w3emc w3nco
  do
     export ${lib}_ROOT=/home/dusan/simple-ufs/NCEPLIBS/local/${lib}
  done

not terrible, but not as convenient as just setting CMAKE_PREFIX_PATH.