[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] Treatment of symbolic link
From: |
Hideki IWAMOTO |
Subject: |
Re: [RFC] Treatment of symbolic link |
Date: |
Tue, 15 Jan 2008 19:39:27 +0900 |
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
- [RFC] Treatment of symbolic link, Shigio YAMAGUCHI, 2008/01/13
- Re: [RFC] Treatment of symbolic link, Jean-Marc Saffroy, 2008/01/14
- Re: [RFC] Treatment of symbolic link, Shigio YAMAGUCHI, 2008/01/14
- Re: [RFC] Treatment of symbolic link, Jean-Marc Saffroy, 2008/01/14
- Re: [RFC] Treatment of symbolic link, Shigio YAMAGUCHI, 2008/01/14
- Re: [RFC] Treatment of symbolic link,
Hideki IWAMOTO <=
- Re: [RFC] Treatment of symbolic link, Shigio YAMAGUCHI, 2008/01/15
- Re: [RFC] Treatment of symbolic link, Hideki IWAMOTO, 2008/01/15
- Re: [RFC] Treatment of symbolic link, Shigio YAMAGUCHI, 2008/01/15