The `npm link` set of commands does use absolute paths. I've tried
setting updater.full_deps (the instructions for compiling with the right
SUID flag are outdated btw), but it seems like it bugs with `preload`
("unable to find node 'src' for preloading in directory 53"). As an
alternative to symlinks, I've chosen to use mounting or
bindfs(http://bindfs.org). They seem to work with Tup/fuse. Symlinks are
still "lightweight" and nice though.
I'd _love_ not needing fuse. It doesn't work 't corporate machines (still
investigating) and it's unclear whether the IT will bother fixing it.
On Thursday, April 28, 2016 at 12:23:27 PM UTC-7, [email protected] wrote:
>
> Symlinks are supported (but hard links are not). However, there are a
> few cases where they might not work:
>
> 1) Your symlink goes outside of the .tup hierarchy (eg: I have
> /home/user/project/.tup and symlink to a file in /home/user). In this
> case, the file in /home/user isn't checked by tup unless you are
> setting updater.full_deps
>
> 2) (On OSX, and Linux if your kernel doesn't support user namespaces)
> - your symlink uses a full path to point back into the tup hierarchy.
> Eg: 'ln -s /home/user/project/foo.txt bar.txt' instead of 'ln -s
> foo.txt bar.txt'. In this case, the symlink escapes out of the FUSE
> filesystem, so the dependency is missed. The ^c flag forces tup to use
> a chroot so this case works, but it makes the performance impact of
> FUSE much worse. This may go away in the future in OSX if we revert to
> a shared library shim instead of FUSE.
>
> Does your use-case fall into one of those two categories? I'm not very
> familiar with npm.
>
> Ideally we'd use updater.full_deps=1 by default, and have a better
> dependency checking mechanism that didn't have the performance impact
> and other peculiarities of FUSE, so these cases would work out of the
> box. Obviously we're not there yet though.
>
> -Mike
>
> On Wed, Apr 27, 2016 at 3:31 AM, Cheng Lou <[email protected]
> <javascript:>> wrote:
> > First of all, to confirm my assumptions: Tup doesn't track changes
> across
> > with symlinks right? E.g. if mySource is symlinked into the current
> project,
> > its changes won't be picked up?
> >
> > I have project A, B, both depending on C. When I'm developing C, I'd
> like to
> > see its changes reflected in both A and B. Realistically I'm working
> with
> > npm (node.js) here, so the workflow looks like:
> >
> > - `npm link` inside C to establish that C can now be linked by other
> > projects.
> > - `npm link C` inside A to link C inside A.
> > - `npm link C` inside B, same.
> >
> > If there's an alternative solution to this, that'd be great. But I can't
> > seem to find a non-hacky one.
> >
> > --
> > --
> > tup-users mailing list
> > email: [email protected] <javascript:>
> > unsubscribe: [email protected] <javascript:>
> > options: http://groups.google.com/group/tup-users?hl=en
> > ---
> > You received this message because you are subscribed to the Google
> Groups
> > "tup-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an
> > email to [email protected] <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
--
--
tup-users mailing list
email: [email protected]
unsubscribe: [email protected]
options: http://groups.google.com/group/tup-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"tup-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
