[Scons-dev] symlink examples for next Parts drop

[William Deegan]

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 at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20121126/27ec0d30/attachment.html>