Re: VPATH question

ished prerequisites of target file 'lib'. > > No need to remake target 'lib'; using VPATH name 'apps/lib'. > >     Finished prerequisites of target file 'default'. > > > > > Only adding 'MAKEFLAGS += --warn-undefined

Re: VPATH question

Paul Smith wrote: If you use "-d" you'll get the info you want: No implicit rule found for 'default'. Considering target file 'lib'. Finished prerequisites of target file 'lib'. No need to remake target 'lib'; using VPA

Re: VPATH question

fault'. > > Why doesn't it understand the meaning of '.'? It does. Make adds the prerequisite to every VPATH entry. Your VPATH entry is "apps" and the prerequisite is "./lib", and so the combination is "apps/./lib" which is a perfectly lega

VPATH question

Hello list. I sometimes have issues when a 'VPATH' doesn't do what I'd like. E.g. in this 'vpath-test.mak' file: # # there is a 'apps/lib' directory here: # VPATH = apps GEN_DIRS = ./lib default all: $(GEN_DIRS) $(GEN_DIRS): mkdir --v

[bug #30829] vpath conflict with file mention in makefile vs file on disk

. Trying implicit prerequisite 'boo.h'. Found prerequisite 'boo.h' as VPATH 'sue/boo.h'. Found implicit rule '%.enu: %.h' for 'boo.enu'. Considering target file 'boo.h'. Looking for an implicit rule for 'boo.h'.

[bug #20394] vpath directive drops entries

Update of bug #20394 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #27556] no rule to build target via vpath when jobserver is unavailable

Update of bug #27556 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #54676] no way to query current vpath value

Follow-up Comment #1, bug #54676 (project make): Actually I think "vpath %.c ?" might be fine. Technically incompatible but the odds of anyone having ever used a directory called "?" seem very low. ___ Reply to thi

[bug #56732] VPATH doesn't work with pattern rules

Update of bug #56732 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #4: This is a duplicate of

[bug #30829] vpath conflict with file mention in makefile vs file on disk

Update of bug #30829 (project make): Item Group:None => Bug ___ Reply to this item at: ___ Messa

Re: [bug #56732] VPATH doesn't work with pattern rules

On 8/10/19 8:16 AM, anonymous wrote: > Follow-up Comment #3, bug #56732 (project make): > > OK, this is a special case I didn't remembered. The wording in the manual > doesn't touch implicit rules, so one can assume it should work for them too. > > I don't know how much application of rules diffe

[bug #56732] VPATH doesn't work with pattern rules

Follow-up Comment #3, bug #56732 (project make): OK, this is a special case I didn't remembered. The wording in the manual doesn't touch implicit rules, so one can assume it should work for them too. I don't know how much application of rules differs between normal and implicit ones, so I can't h

[bug #56732] VPATH doesn't work with pattern rules

Follow-up Comment #2, bug #56732 (project make): Thanks for looking at this. Make supports linker flags as dependencies of a recipe and automatically searches for the .a/.so file using VPATH. See the relevant section of the manual, 4.5.6 "Directory Search for Link Libraries". I s

[bug #56732] VPATH doesn't work with pattern rules

Follow-up Comment #1, bug #56732 (project make): Your example doesn't seem to rely on VPATH in any way. Remember: VPATH is used as a place to look for files. Also you are using "-lAbc" as prerequisite for output/%. It seems you are intending to use linker flags as input to the

[bug #56732] VPATH doesn't work with pattern rules

URL: <https://savannah.gnu.org/bugs/?56732> Summary: VPATH doesn't work with pattern rules Project: make Submitted by: None Submitted on: Thu 08 Aug 2019 11:26:35 AM UTC Severity: 3 - Normal Item

[bug #54676] no way to query current vpath value

URL: <https://savannah.gnu.org/bugs/?54676> Summary: no way to query current vpath value Project: make Submitted by: boyski Submitted on: Tue 18 Sep 2018 01:32:16 AM UTC Severity: 3 - Normal Item

[bug #45477] cygwin: regression in VPATH handling.

Update of bug #45477 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

Re: mingw32-make does not find prerequisites in VPATH when they have forward slashes

On Thu, 2016-06-16 at 18:35 -0600, Erasmo Aguilera wrote: > I am working on a project with two directory trees: one for sources > and another for output files. I run mingw-make from the source tree > and add the output tree root to VPATH so that their files can be found > wh

Re: mingw32-make does not find prerequisites in VPATH when they have forward slashes

> From: Erasmo Aguilera > Date: Thu, 16 Jun 2016 18:35:17 -0600 > > I am working on a project with two directory trees: one for sources and > another for output files. I run > mingw-make from the source tree and add the output tree root to VPATH so that > their files can b

mingw32-make does not find prerequisites in VPATH when they have forward slashes

Hello, I am working on a project with two directory trees: one for sources and another for output files. I run mingw-make from the source tree and add the output tree root to VPATH so that their files can be found when acting as prerequisites. But it doesn't so when such prerequisites sp

[bug #45675] Bugs in VPATH, implicit-rules, pattern-specific, conditionals, wildcard etc.

Update of bug #45675 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: I don't know what this

[bug #45675] Bugs in VPATH, implicit-rules, pattern-specific, conditionals, wildcard etc.

URL: <http://savannah.gnu.org/bugs/?45675> Summary: Bugs in VPATH, implicit-rules, pattern-specific,conditionals,wildcard etc. Project: make Submitted by: None Submitted on: Sun 02 Aug 2015 07:01:25 AM UTC Sever

[bug #45477] cygwin: regression in VPATH handling.

Follow-up Comment #1, bug #45477 (project make): AFAIK, we don't have a Cygwin maintainer on board, and I don't have Cygwin installed on my system. So even if I could come up with a suitable fix, I cannot test it. Therefore, a tested patch to fix this from a Cygwin user will be highly appreciate

[bug #45477] cygwin: regression in VPATH handling.

URL: <http://savannah.gnu.org/bugs/?45477> Summary: cygwin: regression in VPATH handling. Project: make Submitted by: matzeri Submitted on: Sun 05 Jul 2015 08:54:40 PM GMT Severity: 3 - Normal Item

[bug #28189] SIGPIPE when gmake invoked recursively and vpath specified

Update of bug #28189 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #2: I believe this is a du

[bug #34542] vpath windows issues

Update of bug #34542 (project make): Status:None => Works for me Open/Closed:Open => Closed ___ Follow-up Comment #2: Closing as "works for

[bug #34542] vpath windows issues

Follow-up Comment #1, bug #34542 (project make): I cannot reproduce this on my XP SP2 machine. I tried versions 3.80, 3.81, and 3.82, and they all produce the expected output: D:usrelidatatest3>make echo a/foo.c b/bar.c a/foo.c b/bar.c Perhaps you could run Make with the -d switch and see why i

[bug #34542] vpath windows issues

URL: <http://savannah.gnu.org/bugs/?34542> Summary: vpath windows issues Project: make Submitted by: None Submitted on: Thu Oct 13 19:16:49 2011 Severity: 3 - Normal Item Group: Bug

[bug #33499] VPATH does not work with 'Advanced Auto-Dependency Generation' when source file is moved into another location

;t a bug in GNU make, and the contents of and descriptions on non-GNU/FSF websites are not part of GNU make and aren't subject to bug reports in Savannah. The behavior you're seeing is correct, since the auto-generated dependency files contain hardcoded pathnames, they don't use VPATH

[bug #32511] Prerequisite libraries can expand to the system library despite vpath

Update of bug #32511 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

RE: VPATH file rename is not detected by $

Hi, Thanks for looking into this Eddy! The behavior depends on the VPATH directory order e.g. VPATH = a b, mv a => b does not work VPATH = a b, mv b => a works correct VPATH = b a, mv b => a works VPATH = b a, mv a => b does not work To illustrate this better the script attache

Re: VPATH file rename is not detected by $

problem, not the fact that $< is missing. I suspect (although I'm no expert on VPATH) that the fix for this is for your perl script to strip, from each prerequisite listed in the *.d file, any prefix that's present in VPATH. Then the .d.cmd file will list paths relative to VPATH and t

RE: VPATH file rename is not detected by $

Just noticed my colleague has posted the same topic over the web-interface (subject: [bug #33499] VPATH does not work with 'Advanced Auto-DependencyGeneration' when source file is moved into another location). Sorry for this spam. -Original Message- From: bug-ma

[bug #33499] VPATH does not work with 'Advanced Auto-Dependency Generation' when source file is moved into another location

URL: <http://savannah.gnu.org/bugs/?33499> Summary: VPATH does not work with 'Advanced Auto-Dependency Generation' when source file is moved into another location Project: make Submitted by: None Submitted on: Thu 09 Jun

RE: VPATH file rename is not detected by $

achim (EXT-Other - DE/Ulm) Sent: Wednesday, June 08, 2011 9:10 PM To: bug-make@gnu.org Subject: VPATH file rename is not detected by $< Hi, sorry for the bother, I checked the archives but have not found an answer. If there is already a solution please kindly point me to it. Here is the situati

VPATH file rename is not detected by $

Hi, sorry for the bother, I checked the archives but have not found an answer. If there is already a solution please kindly point me to it. Here is the situation: If a source file is renamed and moved from one VPATH to another then $< still points to the old (previous) path. It detects that

[bug #32511] Prerequisite libraries can expand to the system library despite vpath

URL: <http://savannah.gnu.org/bugs/?32511> Summary: Prerequisite libraries can expand to the system library despite vpath Project: make Submitted by: None Submitted on: Thu 17 Feb 2011 03:05:04 AM UTC Severity: 3 -

[bug #30829] vpath conflict with file mention in makefile vs file on disk

URL: <http://savannah.gnu.org/bugs/?30829> Summary: vpath conflict with file mention in makefile vs file on disk Project: make Submitted by: None Submitted on: Fri 20 Aug 2010 04:09:43 PM UTC Severity: 3 -

VPATH and filenames with double-slash `//'

Hello everybody. I think I've found a bug in GNU make, apparently due to the interaction of VPATH and filenames with double-slash `//'. Here is an excerpt showing the most relevant part of the bug: $ cat Makefile VPATH = .. foo_OBJECTS = ./src//foo.o foo: $(foo_OBJECTS)

[bug #28189] SIGPIPE when gmake invoked recursively and vpath specified

Update of bug #28189 (project make): Item Group:None => Bug Triage Status:None => Verified ___ Follow-up Comment #1: In the new CVS code w

[bug #28189] SIGPIPE when gmake invoked recursively and vpath specified

URL: <http://savannah.gnu.org/bugs/?28189> Summary: SIGPIPE when gmake invoked recursively and vpath specified Project: make Submitted by: yozh Submitted on: Sun 06 Dec 2009 02:40:50 AM GMT Severity: 3 -

[bug #2884] Source file not found in vpath when implicit rule triggered by target specified with an absolute path

Follow-up Comment #2, bug #2884 (project make): This bug seems to be corrupted; it's not showing up in my lists anywhere. Maybe because of the "Invalid User ID" stuff in the "Submitted By" field? I do have some info about this so I'll try to re-attach the tar file. Note that the tar file I hav

[bug #27556] no rule to build target via vpath when jobserver is unavailable

URL: <http://savannah.gnu.org/bugs/?27556> Summary: no rule to build target via vpath when jobserver is unavailable Project: make Submitted by: None Submitted on: Mon 28 Sep 2009 09:00:48 PM UTC Severity: 3 -

Re: bug in cleaarcae mvfs for linux confuses make VPATH

think. | | You can just use snapshot views? | (Or don't use clearcase ;-)) Out of my hands that is! (The makefile is part of a tool that has to work with the way things are done here...) | | I suppose having a VPATH across two views will cause problems... | | Supposedly this has been fixed: |

Re: bug in cleaarcae mvfs for linux confuses make VPATH

You seem to be mixing up SDPParser.h and SDPContext.h -- but MVFS file system are not posix compatible -- I ran into this when I tried to diff two trees... You can just use snapshot views? (Or don't use clearcase ;-)) I suppose having a VPATH across two views will cause pro

bug in cleaarcae mvfs for linux confuses make VPATH

VPATH list. This little makefile demonstrates the problem: VPATH := /view/sharman_Platform_Services/vobs /view/sharman_MediaServer_1.0/vobs junk : junk.c NETSVC/NS_Inc/SDPContext.h wc -l

[bug #20394] vpath directive drops entries

Follow-up Comment #7, bug #20394 (project make): As to when to use the cache vs. avoid it, I actually meant the opposite from what you wrote. Maybe it's more clear with a practical example: $ time make -C fltk-1.1.7, up-to-date, on a (slow) Ubuntu box: make (3.81b4, as is): - 3.8 sec make (cvs,

[bug #20394] vpath directive drops entries

Follow-up Comment #6, bug #20394 (project make): I haven't looked into it carefully, but it's not immediately clear to me that it's a simple thing to avoid the directory cache for chained/intermediate rules, vs. any other kind of rule. The disadvantage with the "is_stale" boolean is that every t

[bug #20394] vpath directive drops entries

Follow-up Comment #5, bug #20394 (project make): Timestamps are a different matter, gmake doesn't use the cache to check timestamps of files. Also, what I meant was *chained* rules with intermediate files, not first-level implicit rules. Basically it is so that gmakes spends all win from the cach

[bug #20394] vpath directive drops entries

Follow-up Comment #4, bug #20394 (project make): Something like that could be tricky to accomplish, since make is highly recursive: when make starts checking for timestamps on files it doesn't know whether that file was found using implicit or explicit rules, etc. Plus, I think it would be even

[bug #20394] vpath directive drops entries

Follow-up Comment #3, bug #20394 (project make): It would maybe make sense to rely on the directory cache only for intermediate search and match-anything rules. Because these two alone increase the number of file-queries by a factor of about 10. That is just from the 5 built-in rules (which moreo

[bug #20394] vpath directive drops entries

Follow-up Comment #2, bug #20394 (project make): It's not exactly correct to say that GNU make caches directories from the 10th on, but you're on exactly the right track; thanks for the note. What make actually does is cache EVERY directory... BUT it caches them "lazily", AND it only allows 10 d

[bug #20394] vpath directive drops entries

Follow-up Comment #1, bug #20394 (project make): gmake caches directories from the 10th on. So it will not see a file in those directories if it didn't exist initially (except under windows NT, where it checks the directory timestamps). Just looks like foo1..8 plus lib, include and . were one m

[bug #20394] vpath directive drops entries

URL: <http://savannah.gnu.org/bugs/?20394> Summary: vpath directive drops entries Project: make Submitted by: None Submitted on: Samstag 07.07.2007 um 08:09 UTC Severity: 3 - Normal Item Grou

[bug #17373] Uses VPATH found source name if first double-colon rule doesn't update

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=17373> Summary: Uses VPATH found source name if first double-colon rule doesn't update Project: make Submitted by: None Submitted on: Tuesday 08/08/20

[bug #16286] VPATH and directory cache

Follow-up Comment #4, bug #16286 (project make): Okay, yes, you're right that VPATH isn't intended to do what I thought it would be useful for. That's not a bug, it's a feature. (sorry, couldn't resist) Anyway, what you say about dismisisng the VPATH prefix isn'

Re: [bug #16286] VPATH and directory cache

ker, would it be a good idea to include in the manual some of the stuff from your Web pages? Something like a section "VPATH Pitfalls", perhaps? ___ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make

[bug #16286] VPATH and directory cache

Follow-up Comment #3, bug #16286 (project make): All of the behavior you see, as far as I can tell, is expected. The documentation of vpath shows that if the target needs to be rebuilt then the vpath-qualified pathname is thrown away and the target is rebuilt locally (which means that when this

[bug #16286] VPATH and directory cache

Follow-up Comment #2, bug #16286 (project make): Well, that VPATH is useless for anything except leaf targets is what I figured out on my own after some time of inverstigation. If one has to include the object dirs or whatever all over the place anyway, using VPATH just for leaf targets makes

[bug #16286] VPATH and directory cache

things you say are true (except perhaps the stuff about cosmic x-rays :-)). This is how the VPATH feature is documented to work and it works as documented (if you think there are cosmic x-rays involved please try the latest release, GNU make 3.81, and see if you get the same unexplainable behavior).

[bug #16286] VPATH and directory cache

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=16286> Summary: VPATH and directory cache Project: make Submitted by: None Submitted on: Donnerstag 06.04.2006 um 18:15 UTC Severity:

Re: Invalid VPATH directories query

%% "J. Grant" <[EMAIL PROTECTED]> writes: jg> I have noticed some accidental mistakes with invalid VPATH jg> directories. I wonder if there is any way Make could first check jg> the directories are valid and list the ones which are invalid? Just because they&#x

Invalid VPATH directories query

Hello, I have noticed some accidental mistakes with invalid VPATH directories. I wonder if there is any way Make could first check the directories are valid and list the ones which are invalid? Would such a feature be supported if not already present? (I could not find it) Kind regards JG

Re: Bug#176639: make: documentation of VPATH does not match behavior

%% Manoj Srivastava <[EMAIL PROTECTED]> writes: ms>The value of the `make' variable `VPATH' specifies a list of ms> directories that `make' should search. Most often, the directories are ms> expected to contain prerequisite files that are not in the cu

Re: Two bugs with 3.80? VPATH and usage message

in the FSF version of GNU make. If you're seeing them it means you're using the Cygwin version of GNU make, which has been modified by Cygwin. That version of GNU make is not really supported by this mailing list; please contact the Cygwin development team for problems with that v

Two bugs with 3.80? VPATH and usage message

Here are two findings that I think are bugs. These relate to Make 3.79.1 and 3.80, running under cygwin and Windows XP Professional. In both cases 3.79 does what I expected and 3.80 doesn't. 1) 3.80 seems to ignore VPATH. The following makefile uses three sources in the folder given in

Re: Inconsistent VPATH behavior ..

issue .. >> If that doesn't exist, _then_ it appends the pathname that is given in >> the makefile onto each entry in VPATH, in order, and looks for that. hk> VPATH=/u/p/src hk> install: ../install/scripts/foo hk> $(INSTALL) ..

Re: Inconsistent VPATH behavior ..

. >> If that doesn't exist, _then_ it appends the pathname that is given in >> the makefile onto each entry in VPATH, in order, and looks for that. hk> VPATH=/u/p/src hk> install: ../install/scripts/foo hk> $(INSTALL) ..

Re: Inconsistent VPATH behavior ..

Paul: %% Harsha Kalidindi <[EMAIL PROTECTED]> writes: >> If you run "make install", then make says "OK, I need to build >> ../install/scripts/foo". It looks to see if that file exists. If it >> does, then VPATH is never consulted. hk> We

Re: Inconsistent VPATH behavior ..

%% Harsha Kalidindi <[EMAIL PROTECTED]> writes: >> If you run "make install", then make says "OK, I need to build >> ../install/scripts/foo". It looks to see if that file exists. If it >> does, then VPATH is never consulted. hk> We expec

Re: Inconsistent VPATH behavior ..

If you run "make install", then make says "OK, I need to build ../install/scripts/foo". It looks to see if that file exists. If it does, then VPATH is never consulted. We expect the above behavior. If it doesn't exist, then if VPATH is defined make uses it to

Re: Inconsistent VPATH behavior ..

%% Harsha Kalidindi <[EMAIL PROTECTED]> writes: hk> ../install/scripts/% : % hk> $(INSTALL) -m 444 $(<) $(@) hk> gmake is looking in $(VPATH)/../install/scripts. We are not hk> expecting it to. We expect it to look in VPATH only for sources

Re: Inconsistent VPATH behavior ..

Paul: VPATH is useful only to find source files from the destination directory, it cannot be used to find destination files from the source directory. I think that's what your trying to do here: run make in the source directory and put the results in a different directory. VPATH cannot be

Re: Inconsistent VPATH behavior ..

VPATH is useful only to find source files from the destination directory, it cannot be used to find destination files from the source directory. I think that's what your trying to do here: run make in the source directory and put the results in a different directory. VPATH cannot be used in

Inconsistent VPATH behavior ..

.pl. The problem is when gmake is run in /user/u/src. 1. VPATH is set to /user/p/src. 2. If /user/u/install/scripts/scr.pl exists and if the file /user/u/src/scripts/scr.pl is older then, it is installed. As expected. 3. However, if /user/u/install/scripts/scr.pl d

Re: Bug#176639: make: documentation of VPATH does not matchbehavior

Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian Bug Tracking system can record your input] Info node make(General Search) says: The value of the `make' variable `VPATH' specifies a list of directories that `make' should search.

Re: Is VPATH Iterative?

Thank you very much for your prompt -- and clear -- reply. I'll have my colleague fire up his browser. Regards, Jim Paul D. Smith wrote: >%% Jim Tison <[EMAIL PROTECTED]> writes: > > jt> A colleague of mine asks an interesting question about VPATH. He > jt> clai

Re: Is VPATH Iterative?

%% Jim Tison <[EMAIL PROTECTED]> writes: jt> A colleague of mine asks an interesting question about VPATH. He jt> claims that, within the execution of a single makefile, he has jt> just made an object within a directory path named as one of the jt> VPATH operands (not c

Is VPATH Iterative?

Folks: We're back on 3.76.1 because we're running GNU make on a non-mainstream platform for which the port was done some years ago -- nobody's done the update port to 3.79.1 yet (although I'm giving it serious consideration). A colleague of mine asks an interesting ques

Re: Bug#107624: make: the "-W " option used with VPATH doesnot work correctly

Hi, [Please retain the CC to [EMAIL PROTECTED] so that the Debian Bug Tracking system can record your input] This has been reported by a debian user. There seems to be a strange interaction with the "-W " option when it is used in conjunction with the VPA

Re: vpath bug

ginal (failing) makefile with -p and examine the output, and see if the VPATH pathname there is really the right one from the makefile? -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://

vpath bug

I have the following makefile: vpath %.c c:/usr/Leviticus/cm/RTCS2.76/SOURCE/APPS default : binfile.o %.o: %.c echo "building .o file" $< $@ When I run it, I get the following error: make: *** No rule to make target `binfile.o', needed by `default'. Stop

Re: make version 3.79.1, VPATH problem(?)

%% [EMAIL PROTECTED] writes: rw> Sorry for the missing information, but I use (a part of ) the rw> precompiled cygwin toolset Ah. The Cygwin version of GNU make is not identical to the standard GNU make distributed by the FSF. You should talk to the people at Cygwin about it. I know next

Re: make version 3.79.1, VPATH problem(?)

Dear Paul, Sorry for the missing information, but I use (a part of ) the precompiled cygwin toolset, I was pleasantly surprised that make 3.79 did not pass the /cygdrive/c in the pathname, but this VPATH problem remained. Reading your mail, I may have addressed the problem to the wrong

Re: make version 3.79.1, VPATH problem(?)

If you've built your Windows version of make for Windows32 then I think this is (or should be) all handled automatically. See the README.W32 file for a discussion of how GNU make tries to handle drive specifiers. -- ---

make version 3.79.1, VPATH problem(?)

isual C++ 6.0 I mostly use relative pathnames but sometimes absolue pathnames are required. I use VPATH for this, but my absolute pathname on the pc (c:/myfiles) contains the VPATH separator ':' . The make locates the file foo.c in the directory "/myfiles" and passes "/myf

Re: vpath syntax problem (CORRECTION)

%% Martin Vicente <[EMAIL PROTECTED]> writes: mv> I think i found a probleme with `vpath' syntax in GNU Make version 3.78.1 mv> make: file.c:252: file_hash_enter: Assertion `oldfile != file' failed. mv> Abort (core dumped) mv> Exit 134 I believe this is fi

vpath syntax problem (CORRECTION)

(I miss the line `foo: foo(bar)' in my example) Hello, I think i found a probleme with `vpath' syntax in GNU Make version 3.78.1 System Debian GNU / Linux version 2.2 (potato) kernel 2.2.14 Linux vicente 2.2.14 #8 Thu Mar 23 20:07:10 CET 2000 i5

vpath syntax problem

Hello, I think i found a probleme with `vpath' syntax in GNU Make version 3.78.1 System Debian GNU / Linux version 2.2 (potato) kernel 2.2.14 Linux vicente 2.2.14 #8 Thu Mar 23 20:07:10 CET 2000 i586 unknown +++

entertaining vpath behavior

First off, I *have* read the info pages about vpath and http://www.paulandlesley.org/gmake/vpath.html. I think I know why gmake's doing this, I just don't like it. Consider this Makefile: --CUT--- PWD=$(shell p

Re: vpath problem

%% Russell Smiley <[EMAIL PROTECTED]> writes: No need for HTML on the mailing list; thanks. rs> Please find attached a very simple project that I believe may rs> illustrate a problem with make and its use of vpath. It's not a bug; this is how VPATH was designed by thos

vpath problem

Please find attached a very simple project that I believe may illustrate a problem with make and its use of vpath. The README file contains a description of the problem, and make.log shows the make error output. I hope it is helpful. Russell.   --  Russell Smiley [EMAIL PROTECTED

Re: VPATH

i encountered problems. i'm almost postive it has kc> something to do with the VPATH directive, because on the solaris kc> system it never looks for implicit dependencies. i have included kc> my makefile. can you please help? In general, we can't just debug a while makefile.

VPATH

runs perfectly on my NT system, using version 3.77 version of gnu make for win32 systems.  i then brought it over to a solaris system that also has 3.77 of gnu make, but i encountered problems. i'm almost postive it has something to do with the VPATH directive, because on the solaris syste

Re: conflict between RCS and VPATH

John Gerard Malecki writes: > From: John Gerard Malecki <[EMAIL PROTECTED]> > To: "Albert L. Ting" <[EMAIL PROTECTED]>, [EMAIL PROTECTED], [EMAIL PROTECTED] > CC: Lyndon Lim <[EMAIL PROTECTED]> > CC: "Scott L. Bordelon" <[EMAIL PROTECTED]> &

Re: conflict between RCS and VPATH

ile is newer, does not seem to > alt> work if the location of the RCS'd file is in a directory defined > alt> by VPATH. Enclosed is a tar file but I'll explain the test case. > alt> The directory structure is: > > alt> drwxrwx--- alt 0 2000

Re: conflict between RCS and VPATH

file is newer. alt> The above rule, where the RCS file is newer, does not seem to alt> work if the location of the RCS'd file is in a directory defined alt> by VPATH. Enclosed is a tar file but I'll explain the test case. alt> The directory structure is: alt>

conflict between RCS and VPATH

er, does not seem to work if the location of the RCS'd file is in a directory defined by VPATH. Enclosed is a tar file but I'll explain the test case. The directory structure is: drwxrwx--- alt 0 2000-03-17 17:01 make-bug2/ -rw-rw alt 79 2000-03-17 17:01 make-bug2/Mak