[scm/dev] Ability to build with ip and sp library

[grantfirl]

Identical to #1197, but for scm/dev

Tests Conducted:

SCM RTs

Contributors (optional):

@scrasmussen

[climbfuji]

Looks identical to me!

[grantfirl]

Looks identical to me!

Thanks for reviewing, but I'm probably going to remove the CODEOWNERS file, or just change it to SCM people, from this branch only so that you and others don't get even more requests for reviews. Everything in this branch should have already been reviewed in NCAR/main (and maybe already ufs/dev too, depending on the source of the changes).

[scrasmussen]

@grantfirl We might want to PR in my fork's scm/dev branch of these changes instead of this one? Or, because you have the codeowners changes, use this one but change it to use revert?

I used a revert commit which doesn't change the commit hashes from the main branch. (I think you used cherry-pick which changes the hash) This should make keeping things in-sync easier since the common commits in the main and scm/dev branch will be identical. Then once we have #1187 working in scm/dev we can revert the revert commit and the two branches should match up nicely.

Fyi, I've read about this but haven't much experience using this workflow so I might be wrong!

[grantfirl]

@grantfirl We might want to PR in my fork's scm/dev branch of these changes instead of this one?

I used a revert commit which doesn't change the commit hashes from the main branch. (I think you used cherry-pick which changes the hash) This should make keeping things in-sync easier since the common commits in the main and scm/dev branch will be identical. Then once we have #1187 working in scm/dev we can revert the revert commit and the two branches should match up nicely.

Fyi, I've read about this but haven't much experience using this workflow so I might be wrong!

@scrasmussen OK, I didn't know about the commit hash differences. Won't this continue to be a problem though? Let's say that we start squashing/merging PRs into NCAR/main. Once we pull that into scm/dev, won't there be different hashes then too?

[grantfirl]

@scrasmussen Also, if we go this route (starting from your branch of scm/dev), why do we need a PR? Can't you just push that to the NCAR fork?

[scrasmussen]

@scrasmussen OK, I didn't know about the commit hash differences. Won't this continue to be a problem though? Let's say that we start squashing/merging PRs into NCAR/main. Once we pull that into scm/dev, won't there be different hashes then too?

These are good points and I'm not exactly sure right now. I think squashing/merging PRs into NCAR/main is ok, as long as we then "rebase and merge" those new commits from main into scm/dev. The "rebase and merge" will keep the commit hashes the same.

Not sure how it will work if we start putting new commits on scm/dev and then "rebasing and merging" commits from main->scm/dev or if that is even possible. There might be a bit of growing pains with this new development model

@scrasmussen Also, if we go this route (starting from your branch of scm/dev), why do we need a PR? Can't you just push that to the NCAR fork?

I suppose I could, though going through the PR route creates a better historical record and allows discussion?

[grantfirl]

my fork's scm/dev branch

@scrasmussen OK, so let's just do your branch PR then. I don't think it needs any further discussion though. Tracy, you, and I are effectively the only people who really care about scm/dev and we already discussed this. I'll close this once yours is ready.

[hertneky]

@grantfirl @scrasmussen I think the current plan sounds good. I guess we will see how this new process goes.