RE: ignore specific file in VPATH/vpath

[Jannick]

Hi Paul,

On Fri, 11 May 2018 12:46:57 -0400, Paul Smith wrote:
> On Wed, 2018-05-09 at 14:30 +0200, Jannick wrote:
> > +---build
> > >        makefile
> > >
> >
> > \---src
> >         parse.c <<< disregard for a build in folder 'build'
> >         parse.y
> >         prog.c
> >
> > The nasty thing is src/parse.c which unfortunately does exist, but
> > should be ignored for our project, since build/parse.c should be
> > separately build (from parse.y) and used instead.
> >
> > Currently, I am not able - in an elegant way - to avoid that make uses
> > src/parse.c, unless make -B.
> 
> I think maybe it would help if you backed up a bit... I thought I understood
> what you wanted but then I was totally thrown by this reference to "make -
> B" at the end here.
> 
> Can you explain more clearly?  You seem to be saying that build/parse.c is
> the output from building src/parse.y?  And that's what you want to use to
> create build/parse.o?  Is src/parse.c also that output, or some completely
> different code?  What do you want to do with src/parse.c?

Sorry for apparently being more than even a bit unclear. I am taking the time 
to elaborate in more detail what I want to achieve and what did not work when I 
was writing the posting above:

In general I am headed to a - what is called I think - "VPATH build". The 
following is meant to be a small generic example to discuss the issue. In 
reality, however, it applies to projects with many more source files like 
'src/parse.y' together with 'src/parse.c'.
 
After cd'ing to the folder 'build', the goal is to compile src/parse.y and 
src/prog.c into
prog.exe using the following working steps

a - src/parse.y -[bison/yacc]-> build/parse.c -[gcc] -> build/parse.o
b - src/prog.c -[gcc]-> build/prog.o
c - build/prog.o build/parse.o -[gcc]-> prog.exe

(For clarity I added the redundant prefix 'build/' - redundant, because I said 
that we have already cd'ed to 'build'. I will stick to this notation.)
These steps ignore src/parse.c (it exists as a left-over of another different 
build in the real world case) and it should be ignored in any case in this 
exercise.

1 - Using the following makefile (picked from my first posting; I dropped the 
explicit %.c:%.y rule, since the rule itself is not important and we assume 
that we rely on the built-in yacc rule; this makes the script cleaner for the 
discussion) causes a problem if we say (1.1) a simple 'make' (the culprit 
src/parse.c is used unfortunately), but it is fine if we say (1.2) 'make -B': 

src_dir                 = ../src
prog:                   prog.o parse.o
vpath   %.y             $(src_dir)
vpath   %.c             $(src_dir)

1.1 - A simple command 'make' does not meet our goal, since when make sees 
'src/parse.c' in the course of the search algorithm, it stops and uses this 
file as a prerequisite for build/parse.o. This is because of our rule 'vpath 
%.c $(src_dir)'.

- src/parse.c -[gcc]-> build/parse.o   <<< the culprit! 
- src/prog.c -[gcc]-> build/prog.o
- build/prog.o build/parse.o -[gcc]-> prog.exe

1.2 - 'make -B' is perfectly fine, since then make goes back to 'src/parse.y' 
(given vpath %.y $(src_dir)) to build 'build/parse.c' with the built-in yacc 
rule.

Now let us look at the following variations of the makefile in (1): 

2 - Replacing the two vpath lines by 'VPATH = $(src_dir)' causes the same 
issues as in (1). So this does not solve the problem. (It might get even worse 
if src/parse.o existed; but let's drop that here, since this variant does not 
help anyway.)

3 - Replacing 'vpath %.c $(src_dir)' by the more specific line 'vpath prog.c 
$(src_dir)' does help, since then make is prohibited to consider src/parse.c' 
in the search algorithm. Then for making 'build/parse.o' make has to use either 
'build/parse.c' - if this file exists already - or the rule sequence (a) above 
to build 'build/parse.o' from 'src/parse.y'.  The downside of this solution is 
that in bigger projects we need an explicit line 'vpath f.c $(src_dir)' for 
*each* source file f.c (here all in folder src).

Question - Is there any way to say something like "vpath %.c <list of folder 
names>, but exclude file_1.c, ..., file_n.c' from '%.c'" (i.e. something like 
'A \minus B'? I believe the make syntax does not allow any valid "\minus 
statement" for the file scope, I have not seen any at least, but I might be 
wrong. Or could "$(filter-out ... )" help here with a loop across admissible .c 
files?  

4 - For now I do not have any solution using 'vpath' or 'VPATH', but using the 
prefix idea shields 'src/parse.c' away from make's search algorithm (an 
explicit rule for %.y is needed then):

src_dir                 = ../src
prog:                   prog.o gen-parse.o
gen-%.c:                %.y
                        bison -o $@ $<
vpath   %.y             $(src_dir)
vpath   %.c             $(src_dir)

Using in this case 'VPATH=$(src_dir)' instead - or equivalently on top of - the 
two vpath lines in the makefile (4) above seems to solve the issue in the first 
place. But then it is falling over, because it is a bit too broad in the case 
in which there is a file src/parse.o sitting next to src/parse.c (which is very 
probable in real life). This could make term 'VPATH build' sound a bit 
misleading, since rather 'vpath' statements should be used to better be on the 
very safe side.

> Why do you want to NOT ignore src/parse.c if make -B is provided?

I don’t. My comment regarding 'make -B' refers to the undesired result (1.1), 
albeit (1.2) is fine.

> If make -B is provided what do you want to use src/parse.c for?

Let me reiterate that src/parse.c (together with any files dependent on it) 
should never be used in our exercise. What I wanted to say is that 'make -B' 
did what I wanted make to do, but a simple 'make' command did not and caused 
the trouble.


All in all I hope this can clarify your questions, although this got really 
lengthy. Please let me know otherwise, happy to revisit the explanations above 
or to provide more information. Apologies for the sloppy imprecise language, 
apparently English is not my mother tongue.

In any case many thanks for your time!

Regards,
J.