Help with Bug #19550: Add support for symlinks to standalone builder
lists at mangomultimedia.com
Sat Jul 21 11:59:42 EDT 2018
I can definitely test it out. I wouldn’t worry about symbolic links outside
the folder right now. I don’t believe it affects .frameworks.
On Sat, Jul 21, 2018 at 10:24 AM Brian Milby via use-livecode <
use-livecode at lists.runrev.com> wrote:
> Doing a little digging on this.
> I'm pretty sure this impacts iOS in the same was as MacOS.
> private command __revSBCopyFolder
> User and group is copied if MacOS, but not Linux
> private command __revSBCopyFile
> Probably good that links are handled as files, because they technically
> Prior to line 351 (probably 348), some code will be needed to determine if
> we are currently dealing with a symbolic link. On Linux, aliasReference
> seems to work properly where on MacOS it only works for an actual alias
> (returns empty for a symbolic link). On MacOS, I'm seeing the type is
> actually "rhapslnk" for symbolic links and "MACSalis" for an alias (if
> others can confirm, I can use my code below). Not sure about Windows. So
> something like this:
> put (the platform is "macos" and (tFileType is "rhapslnk" or tFileType is
> "MACSalis") \
> or (the platform is "linux" and aliasReference(pSourceFile) is not
> pSourceFile) into tFileIsLink
> -- this does count on pSourceFile being an absolute link
> I think that the problem is that LC is attempting to copy links like it
> would a binary file which is what is causing the issue. Lines 351-396 need
> to be wrapped in another if statement that properly handles symbolic links.
> if tFileIsLink then
> -- handle link
> -- existing code from 351-396
> end if
> The easy way would be to just copy the symbolic link directly without
> validation. For relative symbolic links within the copied folder
> structure, this should be fine. If the symbolic links point outside of the
> copied structure (i.e. they are absolute to somewhere else in the file
> system), then there could be an issue with the distributed app. The
> problem is that at the point of the copy, you don't have the full path of
> the destination application (just the file itself), so we can't check and
> be sure that the link points inside the app (unless pSettings is an array
> that has that info). We could check to be sure it is on the same volume
> fairly easily. I think it would be good to just flag it as a warning
> instead of an error that halts the build, but would need to dig a bit to
> see if/how that is possible.
> I don't think the links should be traversed at all, but maintained in the
> destination app.
> If I put together an updated file, could you test to see if my solution
> works for you? I just need to make sure I'm copying the link correctly and
> also figure out what to do on Windows.
> On Fri, Jul 20, 2018 at 10:41 AM, Mike Kerner via use-livecode <
> use-livecode at lists.runrev.com> wrote:
> > A couple of thoughts:
> > 1) There might be cases where symlinks should not be traversed, so there
> > probably should be an option to traverse or not
> > 2) There are probably going to be cases where the symlinks are recursive.
> > I think there should definitely be an option to resolve those.
> > On Fri, Jul 20, 2018 at 10:58 AM Trevor DeVore via use-livecode <
> > use-livecode at lists.runrev.com> wrote:
> > > Hi everyone,
> > >
> > > I’m writing this email to see if there is someone who can pitch in and
> > > implement a fix for bug 19550 . The issue is that the the copy
> > > command that the LC standalone builder uses does not support symlinks.
> > > While this hasn’t been a significant problem in the past, it has now
> > become
> > > one because LiveCode Builder (LCB) code can link to .frameworks on
> > > using the Foreign Function Interface (FFI) feature in LiveCode 9.
> > >
> > > As an example, I’ve been working on an LCB wrapper around Sparkle 
> > > on another around MASShortcut . In both cases the .framework needs
> > be
> > > distributed with the LCB library. The Standalone Builder does not
> > a
> > > proper copy of the .framework and the code will fail in a standalone.
> > >
> > > Here is a link to the source code on GitHub that needs to be updated:
> > >
> > >
> > >
> > 16627ebf1f/ide-support/revsblibrary.livecodescript#L215
> > >
> > > If someone is able to step in and modify the existing code to support
> > > symlinks then others would be able to start distributing extensions
> > > use .frameworks on macOS. I haven’t verified whether or not this
> > > iOS but it may.
> > >
> > >  https://quality.livecode.com/show_bug.cgi?id=19550
> > >  https://github.com/trevordevore/lc-sparkle
> > >  https://github.com/trevordevore/lc-masshortcut
> > >
> > > --
> > > Trevor DeVore
> > > ScreenSteps
> > > www.screensteps.com
> > > _______________________________________________
> > > use-livecode mailing list
> > > use-livecode at lists.runrev.com
> > > Please visit this url to subscribe, unsubscribe and manage your
> > > subscription preferences:
> > > http://lists.runrev.com/mailman/listinfo/use-livecode
> > --
> > On the first day, God created the heavens and the Earth
> > On the second day, God created the oceans.
> > On the third day, God put the animals on hold for a few hours,
> > and did a little diving.
> > And God said, "This is good."
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the Use-livecode