Re: [RFC] Treatment of symbolic link

[Hideki IWAMOTO]

Hi. 

Which should the result of "global -f foo/../src/main.c" for the next tree be?
  '/sys/src/main.c' is out of source tree.
     or 
  main             4 src/main.c         main(int argc, char *argv[])


        /home/src/      (a project directory, it has GTAGS)
               +-lib/
               +-src/
                   +-- main.c 
               +-foo (symlink)
                  |
                  |
        /sys/     v
           +-----bar/ (outside of the project, it doesn't have GTAGS)
           +-----src/
                  +-- main.c 

On Tue, 15 Jan 2008 12:17:47 +0900, Shigio YAMAGUCHI wrote...
> > Maybe you don't want to follow links that go out of
> > the source tree
> 
> I completely recalled the reason. Thank you for your
> pointing out.
> 
> Global works in a source tree, that is, a project.
> But symlinks which point an outside directory of the tree
> break this concept. For example,
> 
>       /home/src/      (a project directory, it has GTAGS)
>              +-lib/
>                      +-src/
>              +-foo (symlink)
>                 |
>       +---------+
>       |
>       +-/sys/bar/ (outside of the project, it doesn't have GTAGS)
> 
> Though the 'foo' directory seems to be in the project,
> it is not actually so. It brings an inconvenient operation
> like follows:
> 
> $ cd /home/src
> $ global -x main
> main           10 src/main.c main(int argc, char *argv[])     <- work well
> $ cd foo
> $ global -x main
> global: GTAGS not found.                                      <- doesn't work
> $
> 
> I felt this imperfect, and made a decision to ignore symlinks.
> But now, I think it should be left to the users.
> 
> > In other words: garbage in, garbage out, right? ;)
> 
> Right.
> I want to remove limitations as much as possible, and
> expand the width of the selection of users.
> 
> Though symlinks which points an outside directory of the
> source tree might confuse global(1), the user can avoid
> the problem by setting variables GTAGSROOT, and in htags(1),
> there is (maybe) no problem.
> 
> I would like to add a disclaimer like follows to the online manual of 
> gtags(1).
> 
>  Global(1) works in a source tree, that is, a project.
>  Symlinks which points an outside directory of the
>  project might confuse global(1). You should understand
>  what you are doing.
> 
> > Well, here is my user point of view: most of the time I use global on an 
> > already existing source tree (I often work in open source software 
> > integration in my day job, and global helped me a LOT), with a layout 
> > intended for eg. the build system, and not for global. So, for me, it is 
> > best if I don't have to "fix" the tree because it confuses global (eg. 
> > dangling symlinks seemed to be a problem). But as of today, I can live 
> > with global as it is. :)
> 
> I heard such opinions from other people too.
> --
> Shigio Yamaguchi <address@hidden> - Tama Communications Corporation
> PGP fingerprint: D1CB 0B89 B346 4AB6 5663  C4B6 3CA5 BBB3 57BE DDA3
> 
> 
> _______________________________________________
> Bug-global mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/bug-global

----
Hideki IWAMOTO  address@hidden