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
http://two.pairlist.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
Scons-dev@scons.org
http://two.pairlist.net/mailman/listinfo/scons-dev