NOAA-EMC / NCEPLIBS-bacio

This library performs binary I/O for the NCEP models.
Other
2 stars 6 forks source link

Upgrade spack package file to include 2.6.0 release and develop branch #142

Open edwardhartnett opened 1 year ago

edwardhartnett commented 1 year ago

We need to update the spack package file for the new release.

We also want to be able to use the develop branch.

In the package file we have this:

    # Prefer version 2.4.1 because the library and include directory
    # names changed in verion 2.5.0 (dropping the "_4" they used to
    # contain.) We need some time to let all the using packages adjust
    # to the new names.
    version(
        "2.4.1",
        sha256="7b9b6ba0a288f438bfba6a08b6e47f8133f7dba472a74ac56a5454e2260a7200",
        preferred=True,
    )

How long will we need to prefer 2.4.1? @AlexanderRichert-NOAA do you think we can easily list all the packages that use bacio in other spack builds? Is there a way to list that?

edwardhartnett commented 1 year ago

I note that the current build has the following:

variant("pic", default=True, description="Build with position-independent-code")

I don't think we want this on by default. In the UFS build everything is built statically and we don't want PIC because it may be slightly less fast.

In versions 2.6.0 and greater we will instead have shared vs. static build. I'm not sure what the default should be. @AlexanderRichert-NOAA and @climbfuji do you have any thoughts on whether shared or static should be the default build?

I think most of the programming world would say shared should be the default. But the UFS is built statically, so maybe that should be our default?

AlexanderRichert-NOAA commented 1 year ago

re: static vs. shared, I would say let's have shared by default, then we can specify static as necessary for UFS (which is already how it is for a lot of the UFS dependencies).

As far as PIC, we could always set it so it's only the default when shared is used, but allow it either way.

Spack packages that depend on bacio are: grib-util, nemsio, ufs-utils, ufs-weather-model, upp, w3emc

As far as which package is "preferred," unless we have some particular reason to want users to keep using the old one, I would say we can just take that out and by default Spack will prefer the most recent non-develop version.

edwardhartnett commented 1 year ago

The problem is that after the preferred version we took away the _d/_8/_4 builds, and just have libbacio. So the library changed names and packages that use it must link to the new name.

This is already done for grib-util, nemsio, ufs-utils, and w3emc.

I will check the rest. How did you learn which packages depend on bacio?

AlexanderRichert-NOAA commented 1 year ago

Fair enough.

I cloned the spack repo, then grepped the package.py's for depends_on("bacio"). You can also use the spack dependents bacio command but it's pretty slow.

edwardhartnett commented 1 year ago

Under ufs-weather-model, after doing a recursive init of submodules, I find:

./WW3/model/src/CMakeLists.txt:  find_package(bacio REQUIRED)
./WW3/model/src/CMakeLists.txt:  target_link_libraries(ww3_lib PUBLIC g2::g2_4 bacio::bacio_4 w3emc::w3emc_4)
./CMakeLists.txt:find_package(bacio 2.4.0 REQUIRED)
./FV3/CMakeLists.txt:                                    bacio::bacio_4
./FV3/upp/CMakeLists.txt:find_package(bacio REQUIRED)
./FV3/upp/sorc/ncep_post.fd/CMakeLists.txt:  bacio::bacio_4