[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: why doesn't vpath %.c subdir// work?
From: |
Philip Guenther |
Subject: |
Re: why doesn't vpath %.c subdir// work? |
Date: |
Mon, 15 Feb 2010 18:04:14 -0800 |
On Mon, Feb 15, 2010 at 12:48 AM, Mark Galeck (CW) <address@hidden> wrote:
...
>>Regardless, if "foobar/" works and "foobar//" doesn't work, then why
> are you writing the latter?
>>"Doctor, it hurts when I do this?" "So stop doing that!"
>
> C'mon Philip, this is bad analogy, obviously, it must be that I need it for
> something.
No, that's not obvious at all. I've seen plenty of questions that
were asked out of pure curiosity.
Secondly, you don't "need" this; you "need" the solution to the actual
problem that you're trying to solve. If there's another way to solve
your problem that doesn't involve using double-slashes in vpaths are
you *really* going to ignore it because you've decided that the only
acceptable solution is one that uses double-slashes?
> What makes you think I am a masochist??
That's just too easy a straight-line.
> OK if you really want to know...
> This is "syntactic sugar", a "marker", I use it so that when the compiler
> returns such paths to me, it preserves the marker, or rearranges it in a
> predictable way, so I can process statistical information about the usage of
> the paths. Not source paths really, these are cheap to search, but include
> paths, which are very expensive because of the number of include files per
> one source. I put markers in both include paths and source paths, they have
> to differ in a certain way. It would be better for me to use // if it worked
> in a vpath. Because it does not work, the next thing I can use is like
> \.\.\, this is longer and uglier, people notice and ask questions. By
> statistically and dynamically optimizing the usage of compiler directory
> lookup, I can dramatically cut down long build times.
Hmm, so you're looking for some way to tag some paths in *some* of
their uses, but not in all of them, so that you can later examine the
build output (just the output of 'make'? auto-dependency files too?)
to determine when and where the paths were used in their tagged forms?
Tagging would be done inside the source files (the #include lines,
presumably) only? Or also in the -I options passed to the compiler?
Philip Guenther
- why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/14
- Re: why doesn't vpath %.c subdir// work?, Philip Guenther, 2010/02/14
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/15
- Re: why doesn't vpath %.c subdir// work?, Eli Zaretskii, 2010/02/15
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/15
- Re: why doesn't vpath %.c subdir// work?, Eli Zaretskii, 2010/02/15
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/15
- Re: why doesn't vpath %.c subdir// work?, Eli Zaretskii, 2010/02/15
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/15
- Re: why doesn't vpath %.c subdir// work?,
Philip Guenther <=
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/16
- Re: why doesn't vpath %.c subdir// work?, David Boyce, 2010/02/16
- RE: why doesn't vpath %.c subdir// work?, Mark Galeck (CW), 2010/02/17
- Re: why doesn't vpath %.c subdir// work?, David Boyce, 2010/02/17
- Re: why doesn't vpath %.c subdir// work?, David Boyce, 2010/02/17
- Re: why doesn't vpath %.c subdir// work?, Philip Guenther, 2010/02/17