So at the moment I don't try to handle a directory, I personally have concerns
about certain behavior, so I left this to round two of fixes to this code.
However the person here that I task to write this, believes that there should
be no real different from the user point of view, ie the difference can be
hidden, and we probably don't need a SymbolicDirLink node etc... we only really
care if the linkto value of the node is a Dir or File when we try to create the
symlink on disk. I am leaning this way this way myself, but am not 100%
committed that this is true yet.
So more examples.
Adir=env.Dir('A')
Nodes=env.SymLink("dirlinktoA",Adir)
env.CCopy('#foo',Nodes+[Adir]) # note we want to copy Directory A as well!
this would make a directory
foo/
dirlinktoA # symlink that points to A
A/
<Whatever is in A>
This works on Linux I believe.. but on other systems link windows this does not
work at the moment. The reason is that under the covers the API to do this on
windows requires an argument to say if the link is to a directory or a file. At
the moment the code assumes a File.
What I think needs to be clear and what I keep bumping against, is the idea
that I am going to copy a directory as a symlink and copy the files in this
directory into the symlink directory as symlink to the original file. This is
something you don't do, and is why I make a big deal the Symlink is a File node
type with the base class being a File, and the name being FileSymbolicLink. You
would be amazed how many Linux people mess this up at first, before they
realize why that was "stupid" once they remember that the directory is
container, and the symlink point to container ( and as such there is no need to
copy stuff into the container from the container). Because of this I am a
little unsure of the directory issue in the current design.. only because I
have lacked the cycles to think it all the way through for these cases. ( I
have been busy getting my start up time for a 100+K node project with 1000
different parts down to 20 seconds from the 2+ minutes on rebuilds.[ and that
was down from the 5 to ten minutes it can take with raw scons logic]) I get a
little paranoid on subject like this, and want make sure the design can change
in reasonable direction, as I have found that project like libraries and build
tools can get used in way that are hard to foresee. I do believe what we got (
minus the issue on windows with directories) is probably correct, and the idea
of needing different node type for the symlinks is probably not needed, but if
it is the node is named to make it easy to define a directory symlink type,
etc...
Does this answer your questions?
Jason
From: scons-dev-boun...@scons.org [mailto:scons-dev-boun...@scons.org] On
Behalf Of William Deegan
Sent: Monday, November 26, 2012 7:49 PM
To: scons-dev@scons.org
Subject: Re: [Scons-dev] symlink examples for next Parts drop
Jason,
How does it handle symlinking a directory?
-Bill
On 11/26/2012 03:04 PM, Kenny, Jason L wrote:
Hi guys,
Been busy trying to fix up stuff on my end. As I said I had some code to help
deal with symlinks, that I think will be useful for SCons.
In this mail I will try to describe what we have and provide some simple
examples of use it.. for possible review on how we might improve it for getting
it into SCons.
This is basically from my current draft version of the release notes for 0.10.2
drop of Parts I hope to make this week.
Symlinks
Symlinks have been refactored and made to work much better. Parts add a class
of SCons.Node.FS.FileSymbolicLink to handle symbolic links in the Scons node
tree, which is subclassed from SCons.Node.FS.File. This node is not used
directly by the user, but is instead returned by some factory functions in the
environment much like File, Dir, Alias, and Value objects are. There are two
API function for creating symlinks, and one for easy handling of existing links
on the system.
To create a symbolic link use the function
env.SymLink(name, linkto,**kw)
name is the name of the link, like any normal File() would be created in Scons
linkto is the File or string object for the link to point to.
**kw is optional set of value to override or add the environment used to build
the symlink
To resolve a exist link on disk or to help define a full list of node from a
chained call of Symlink() function use the function
env.ResolveSymLinkChain(link)
Link is the string to an exist symbolic link on disk or
SCons.Node.FS.FileSymbolicLink node.
Example:
Copy over an existing symlink and the files it points to, into the InstallLIb()
location
env.InstallLib(
env.ResolveSymLinkChain(
"/usr/lib/libc.so"
) # will return a list such as [/usr/lib/libc.so, /usr/lib/libc.so.6]
)
Compile a shared library and make some symlinks to it.
Without ResolveSymLinkChain():
# create the SO lib ( note.. You may need add certain flags such as
-Wl,-soname,libsymlink.so.1.0 depending on your system)
targets = env.SharedLibrary('symlinks', source = 'symlinks.c',
SHLIBSUFFIX='.so.1.0')
#create symlinks based off return target list
targets += env.SymLink('${SHLIBPREFIX}symlinks${SHLIBSUFFIX}',
linkto=targets[0], SHLIBSUFFIX='.so.1')
targets += env.SymLink('${SHLIBPREFIX}symlinks${SHLIBSUFFIX}',
linkto=targets[-1], SHLIBSUFFIX='.so')
# install values to the install sandbox libs directory
env.InstallLib(targets)
With ResolveSymLinkChain():
targets = env.SharedLibrary('symlinks2',source =
'symlinks2.c',SHLIBSUFFIX='.so.1.0' )
# in this case ResolveSymLinkChain return the chain of node pointed by the
libsymlinks2.so node
env.InstallLib(
env.ResolveSymLinkChain(
env.SymLink(
'libsymlinks2.so',
env.SymLink(
'libsymlinks2.so.1',
targets[0]
)
)
)
)
The above examples should look a little like what was being worked on now to
get symlink versioning working in SCons. I think a small change to the builder
for posix like systems to process a
env.SharedLibrary(....,GNU_VERSIONING=Version("1.2.3")) # will do gnu/soname
style versioning generation of the binary and symlinks.. adds needed flags.
Don't get stuck on GNU_VERSIONING, as a name.. I only suggest it as I don't
know what a better name is.
might be a nice way to go in Parts depending on what SCons does in the intern.
Please let me know any thoughts or question you have, so I can clarify any
points of what we have. Also to be clear this works on windows, Linux ( ie host
platform = posix), Mac, I believe Solaris was tested as well.
Hopefully this is a good reduce API that would be reasonable to add to Parts. I
should not I am not sure if adding a Dir or Entry version of the symlink node
will be needed or useful. The main thought is that all symlinks are files, but
the items they point to may not be a file.. so having different forms may be
useful for saying something about we would point to in the end.. ie this better
be a file, or this better be a directory. Likewise some systems make a small
difference in command or API call when you make a symlink to a directory vs a
file.
Jason
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org<mailto:Scons-dev@scons.org>
http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev
