help-make
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]