Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

scons doesn't handle symlinks as targets very well. #1947

Open
bdbaddog opened this issue Jan 2, 2018 · 0 comments
Open

scons doesn't handle symlinks as targets very well. #1947

bdbaddog opened this issue Jan 2, 2018 · 0 comments
Labels
symlink Issues involving symbolic links Version: 0.97

Comments

@bdbaddog
Copy link
Contributor

bdbaddog commented Jan 2, 2018

This issue was originally created at: 2008-03-12 19:00:58.
This issue was reported by: puntium.

puntium said at 2008-03-12 19:00:58

I have code that looks like this:

linknode = env.Command(
    "foo",
    [],
    "ln -sf $TARGET $LINK_SOURCE",
    LINK_SOURCE=File("bar"),
)

This mostly works whenever the link target exists. SCons totally breaks when it doesn't though. There are some legitimate cases where you'd like to have a symlink that points to an non existent path.

In our specific case, we need to create a symlink in a boot image that points to a directory that gets populated at runtime, not at build time. A directory scanner picks up the symlink node, but when it tries to verify its presence, it fails because exists() fails on a symlink that points to nothing.

SCons should be able to support these. Perhaps a new kind of node is warranted. You can kind of think of a symlink as any other kind of file, except that the "content" is the target path of the link (and not the contents of the file pointed to)

gregnoel said at 2008-04-06 14:56:36

Could you make it depend on a Value node? Would that help by finessing the scan?

linknode = env.Command('foo', Value('bar'), 'ln -sf $TARGET $SOURCE')

puntium said at 2008-04-06 23:24:45

Hmm..

I think using the Value node gets part of the way, but its really when you have something that depends on the symlink node that you run into problems.

At some point scons will try to check if the symlink exists. At this point, if the symlink points to an existing file, then scons will happily move along, but if it doesn't, then it will just die saying the file doesn't exist (even if the symlink does exist)

You get around that by making the symlink depend on the file, so that scons makes sure the link target is around before it tries to use the symlink for anything. But again, that limits the use of symlinks.. our scenario was that we wanted to create a symlink that pointed to a /dev path that was for use in an initrd type image.. so the /dev path only existed on the system that booted the image, not the on the system building the image.

gregnoel said at 2008-04-07 11:55:42

Yeah, you're right. I wrote that in a haze of 'flu medications; I'm surprised it made any sense at all. I'll think about it some more.

gregnoel said at 2008-04-14 20:20:02

Bug party triage: Potentially destabilizing, so scheduling it for 1.x is chancy. Put it in 2.x with some priority so it will be pulled up if there are cycles to work on it. (Ken, it would be good if you could throw some votes at it.)

gregnoel said at 2008-06-30 17:07:34

Collect all symlink-related issues into a group with the keyword 'symlink'

gregnoel said at 2008-12-26 13:30:41

Adjust triage of issues.

garyo said at 2012-09-01 10:04:01

de-assigning all tickets assigned to Greg Noel (no longer working on SCons)

@bdbaddog bdbaddog added this to the 2.x milestone Jan 2, 2018
@mwichmann mwichmann removed this from the 2.x milestone Mar 26, 2021
@mwichmann mwichmann added symlink Issues involving symbolic links and removed P3 labels Mar 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
symlink Issues involving symbolic links Version: 0.97
Projects
None yet
Development

No branches or pull requests

2 participants