[Scons-dev] symlink examples for next Parts drop

[Kenny, Jason L]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://two.pairlist.net/pipermail/scons-dev/attachments/20121126/d61f209f/attachment-0001.htm>