On Mon, May 15, 2017 at 3:01 PM, Ryan Gonzalez <[email protected]> wrote: > I'm not going to go into the use case right now, but here's a basic example: > > > ryan@DevPC-LX ~ $ mkdir tup-links > ryan@DevPC-LX ~ $ cd tup-links/ > ryan@DevPC-LX ~/tup-links $ mkdir dir1 dir2 > ryan@DevPC-LX ~/tup-links $ echo 123 > dir1/x.in > ryan@DevPC-LX ~/tup-links $ cd dir2 > ryan@DevPC-LX ~/tup-links/dir2 $ ln -s ~/tup-links/dir1 dir1 > ryan@DevPC-LX ~/tup-links/dir2 $ howl Tupfile # This is just to > edit the Tupfile... > ryan@DevPC-LX ~/tup-links/dir2 $ cat Tupfile > : dir1/x.in |> cp %f %o |> x.out > ryan@DevPC-LX ~/tup-links/dir2 $ ls dir1 > x.in > ryan@DevPC-LX ~/tup-links/dir2 $ tup init
One problem with doing the 'tup init' here is that even if the symlink directory worked, tup wouldn't see the fact that you changed dir1/x.in since it is outside of the tup hierarchy. You would probably want to run 'tup init' one level higher. Alternatively, updater.full_deps=1 should pick it up if necessary. However, that's not actually causing the error you're seeing, just a heads up. > .tup repository initialized. > ryan@DevPC-LX ~/tup-links/dir2 $ tup > [ tup ] [0.121s] Scanning filesystem... > [ tup ] [0.254s] Reading in new environment variables... > [ tup ] [0.376s] Parsing Tupfiles... > * 1) [0.002s] . > tup error: Explicitly named file 'x.in' not found in subdir 'dir1' > tup error: Error parsing Tupfile line 1 > Line was: ': dir1/x.in |> cp %f %o |> x.out' > *** tup: 1 job failed. > [ ] 100% > ryan@DevPC-LX ~/tup-links/dir2 $ ls dir1 > x.in > ryan@DevPC-LX ~/tup-links/dir2 $ The problem here is that when parsing rules, tup is looking inside the tup database, not the filesystem. In other words, even though 'ls dir1/x.in' works, the tup database doesn't have a node for both tup-links/dir1/x.in and tup-links/dir2/dir1/x.in. This is more similar to running the 'find' command from where you ran 'tup init': $ find . . ./dir1 ./.tup ... (more .tup/*) ./Tupfile Notice how dir1/x.in isn't listed, even though 'ls dir1/x.in' shows a result. Tup is essentially looking at the list of files it finds by walking the tree, which does not include following symlinks. I'm not really sure what it would take to add this, or what underlying assumptions might be invalidated by supporting it. Can you elaborate a bit more on the actual use case? Maybe there is an alternative solution that tup would support more easily. -Mike -- -- 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.
