[Scons-dev] symlink examples for next Parts drop

[Kenny, Jason L]

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-bounces at scons.org [mailto:scons-dev-bounces at scons.org] On Behalf Of William Deegan
Sent: Monday, November 26, 2012 7:49 PM
To: scons-dev at 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 at scons.org<mailto: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/20121127/0c616aae/attachment.html>