Skip to content

New command line#29

Merged
scheibelp merged 3 commits intospack:mainfrom
johnwparent:new-command-line
Apr 24, 2026
Merged

New command line#29
scheibelp merged 3 commits intospack:mainfrom
johnwparent:new-command-line

Conversation

@johnwparent
Copy link
Copy Markdown
Collaborator

CLI: Remove deploy

We're no longer modifying binaries on BC push

Based on #28

@johnwparent johnwparent mentioned this pull request Jan 31, 2026
We're no longer modifying binaries on BC push

Signed-off-by: John Parent <john.parent@kitware.com>
Signed-off-by: John Parent <john.parent@kitware.com>
Copy link
Copy Markdown
Member

@scheibelp scheibelp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question and one request

Comment thread src/winrpath.cxx Outdated
Comment thread src/winrpath.cxx
}

/*
* Actually performs the DLL rename, given the DLL location in mapped memory view
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this generally handled elsewhere now? given

    if (SpackInstalledLib(dll_path)) {
        return true;
    }

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you're referring to the sigil code? No we no longer use that. It occurred to me that at best they served 0 purpose and at worst they were actively making relocation harder from a BC installation.

The primary purpose they serve was to identify whether a given dll reference is from spack or not, we always know it's a spack path by virtue of the fact there is a path. If somehow another tool also does that, the path will need relocation anyway, and if it cant be relocated, then the dll would be broken anyway and we'd want to know about it, so at best they're wasted IO.

At worst, they obliterate the beginning of the dll path, which means when we do relocation and go to re-write the dll names to use the new install prefix, we can't (or its much harder and more fragile) determine the relative path of the dll to the install root as we no longer have the old install root in the dll.

Signed-off-by: John Parent <john.parent@kitware.com>
Copy link
Copy Markdown
Member

@scheibelp scheibelp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I recommend making some doc edits in a follow up

Comment thread src/winrpath.cxx
*
*/
bool LibRename::ExecuteRename() {
// If we're not deploying, we're extracting
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably should be reworded

Comment thread src/winrpath.cxx
*
* \param pe the PE file for which to perform the rename of imported (and exported) DLL names
* \param full a flag indicating whether or not we're renaming a PE file and import lib or just an import lib
* \param deploy a flag indicating if we're deploying a binary to a Spack build cache or extracting it
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be removed

@scheibelp scheibelp merged commit 52e5cf7 into spack:main Apr 24, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants