[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: directory search fails!
From: |
ali hagigat |
Subject: |
Re: directory search fails! |
Date: |
Sat, 25 Sep 2010 14:34:53 +0330 |
Eli,
Your description seems better than the manual in my opinion. You
deleted the word, 'target' in Step 4.
Could you make a pdf file only one paragraph, "4.4.3 How Directory
Searches are Performed",
with your style, to compare it with the present manual completely. Not
to see symbols like @var{P}, etc.
Thank you.
On Thu, Sep 23, 2010 at 12:49 PM, Eli Zaretskii <address@hidden> wrote:
>> From: Paul Smith <address@hidden>
>> Date: Wed, 22 Sep 2010 17:56:34 -0400
>> Cc: address@hidden
> address@hidden Search Algorithm, Recipes/Search, Selective Search, Directory
> Search
> address@hidden How Directory Searches are Performed
> address@hidden algorithm for directory search
> address@hidden directory search algorithm
>
> When a prerequisite of a target is found through directory search,
> regardless of type (general with @code{VPATH} or selective with
> address@hidden), the pathname found by the search may not be the one
> that @code{make} actually uses for updating that target. Sometimes
> the path of a prerequisite discovered through directory search is
> thrown away.
>
> This section describes the details of the decision whether or not to
> keep the path of a prerequisite found through directory search.
>
> The algorithm @code{make} uses to decide whether to keep or abandon a
> path or a prerequisite (denoted as @var{P} below) found via directory
> search is as follows:
>
> address@hidden
> address@hidden
> If a prerequisite file @var{P} does not exist at the path specified
> in the makefile, directory search is performed.
>
> address@hidden
> If the prerequisite @var{P} is found via directory search, the
> pathname under which @code{make} found @var{P} is tentatively recorded
> as the actual prerequisite. (This is a tentative decision, because it
> could be reversed later, see below.)
>
> address@hidden
> All the prerequisites of @var{P} are examined using this same method,
> i.e.@: by using directory search if the file specified by the makefile
> does not exist.
>
> address@hidden
> After recursively processing all the prerequisites of @var{P},
> address@hidden decides whether or not @var{P} needs to be rebuilt. This
> decision affects whether the actual pathname of @var{P} found by
> directory search is kept:
>
> address@hidden a
> address@hidden
> If @var{P} does @emph{not} need to be rebuilt, the actual pathname of
> address@hidden found during directory search is used in any prerequisite
> lists which contain @var{P}. In other words, if @code{make} doesn't
> need to rebuild a prerequisite, then it uses its pathname found via
> directory search when it processes targets which depend on this
> prerequisite.
>
> address@hidden
> If @var{P} @emph{does} need to be rebuilt (is out-of-date), its actual
> pathname found during directory search is @emph{thrown away}, and
> address@hidden is rebuilt at the literal location specified in the makefile.
> In other words, if @code{make} must rebuild a prerequisite, then it is
> rebuilt locally, not in the directory found via directory search.
> address@hidden enumerate
> address@hidden enumerate
>
> This algorithm may seem complex, but in practice it is quite often
> exactly what you want.
>
> address@hidden traditional directory search (GPATH)
> address@hidden directory search, traditional (GPATH)
> Other versions of @code{make} use a simpler algorithm: if the file
> does not exist, and it is found via directory search, then that
> pathname is always used whether or not it needs to be built. Thus, if
> the prerequisite is rebuilt, it is created at the pathname found
> during directory search, and that pathname is used for any targets
> which mention the prerequisite in their prerequisite lists.
>
> address@hidden GPATH
> If, in fact, this is the behavior you want for some or all of your
> directories, you can use the @code{GPATH} variable to indicate this to
> address@hidden
>
> address@hidden has the same syntax and format as @code{VPATH} (that is, a
> space- or colon-delimited list of pathnames). If an out-of-date target
> is found by directory search in a directory that also appears in
> address@hidden, then that pathname is not thrown away. The target is
> rebuilt using the expanded path.
>
- Re: directory search fails!, (continued)
- Re: directory search fails!, ali hagigat, 2010/09/22
- Re: directory search fails!, Paul Smith, 2010/09/22
- Re: directory search fails!, Eli Zaretskii, 2010/09/23
- Re: directory search fails!, ali hagigat, 2010/09/25
- Re: directory search fails!, Eli Zaretskii, 2010/09/25
- Re: directory search fails!, ali hagigat, 2010/09/25
- Re: directory search fails!, ali hagigat, 2010/09/25
- Re: directory search fails!, Eli Zaretskii, 2010/09/25
- Re: directory search fails!, Noel David Torres Taño, 2010/09/25
- Re: directory search fails!, Eli Zaretskii, 2010/09/25
- Re: directory search fails!,
ali hagigat <=
- Re: directory search fails!, Eli Zaretskii, 2010/09/25
- Re: directory search fails!, ali hagigat, 2010/09/26
- Re: directory search fails!, Paul Smith, 2010/09/26
- Re: directory search fails!, ali hagigat, 2010/09/27
- Re: directory search fails!, Paul Smith, 2010/09/27
- Re: directory search fails!, Eli Zaretskii, 2010/09/27
- Re: directory search fails!, Paul Smith, 2010/09/28
- Re: directory search fails!, Eli Zaretskii, 2010/09/28
- RE: directory search fails!, David Ferguson, 2010/09/28
- Re: directory search fails!, Eli Zaretskii, 2010/09/28