[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: auto-dep cannot possibly work?
From: |
Mark Galeck (CW) |
Subject: |
RE: auto-dep cannot possibly work? |
Date: |
Mon, 16 Nov 2009 09:33:33 -0800 |
Well, I promised not to argue anymore about whether it is bizarre or not so I
will have to uphold my promise unless you release me from it :)
I would still have to tell developers "if you do this bizarre thing, then
rebuild everything", and they would have to check your IFs, let's say I agree
with your on the number of IFs :) so they would have to check all your 3 IFs,
and then rebuild the whole thing - that's a lot of work for them when they
"expect" this whole thing would be taken care of by me.
So instead, the solution I have is, to add to the original dependencies, as
explained in the GNU make manual, the ones of the following kind:
include/foobar.h: $(wildcard include1/foobar.h include2/foobar.h ...)
where the files in the wildcard, are all the potential include files, with the
same name foobar.h, that, if present, would go before the target
/include/foobar.h in the compiler search path.
I think this is an elegant solution - notice how it not only solves this
bizarre problem, but also notice how nicely it takes care of the catch-22 that
happens if the user deletes include/foobar.h.
Please anybody tell me if you see any problem with this. (Of course, one needs
to generate the list of potential include files, which is a substantial Perl
program, and I am working on it now).
Otherwise, in my humble opinion, it would be good to mention this in the
section: "Generating Prerequisites Automatically" of the GNU manual, since it
not only solves the bizarre problem, but also the less bizarre one of deleting
a header file.
>So, they are going to add a new header file to this directory. Now
EVERY source file that used to include /include1/config.h, and worked
fine and expected that, will start using /include/config.h the next time
it's compiled.
>And that's OK? Not a problem? No other changes need to be made to the
source code? It just seems unlikely to me.
- RE: auto-dep cannot possibly work?, (continued)
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- Re: auto-dep cannot possibly work?, Paul Smith, 2009/11/15
- is it possible to have a prerequisite, which, when non-existent, causes make to ignore it?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- Re: auto-dep cannot possibly work?, Stephan Beal, 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/15
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/15
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?,
Mark Galeck (CW) <=
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- RE: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/17
- Re: auto-dep cannot possibly work?, Mike Shal, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- Re: auto-dep cannot possibly work?, Mike Shal, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16
- Re: auto-dep cannot possibly work?, Paul Smith, 2009/11/16
- RE: auto-dep cannot possibly work?, Mark Galeck (CW), 2009/11/16