> I was thinking to build the objects but not the dependencies. We do a lot
> of one-time only builds, where we don't need dependencies at all.
In that case, leave out the include of any .d whose .o doesn't exist;
you fatuously know you need to build the .o, so you don't need to know
its dependenc
On Wed, 2015-09-23 at 15:00 -0500, John Westing wrote:
> > You are doing exactly Basic Auto-dependencies. But that works because
> > of the re-exec if include files are rebuilt
>
> I don't think that's true, as the author explains in regards to the
> basic method:
>
> "Let’s address the first pr
>> 1. For the code that I'm supporting includes are rarely changed.
> All the more reason to ensure dependencies are updated automatically, as
> people will forget to do it otherwise.
Point taken.
> You are doing exactly Basic Auto-dependencies. But that works because
> of the re-exec if includ
On Wed, 2015-09-23 at 12:48 -0500, John Westing wrote:
> Here are a few points:
>
> 1. For the code that I'm supporting includes are rarely changed.
All the more reason to ensure dependencies are updated automatically, as
people will forget to do it otherwise.
> 2. By default I will always rebui
Here are a few points:
1. For the code that I'm supporting includes are rarely changed.
2. By default I will always rebuild dependencies (the all rule I showed).
For this case I thought about it for a few minutes I don't think
dependencies will become out of date if auto-remaking doesn't occur (a
On Wed, 2015-09-23 at 12:15 -0500, John Westing wrote:
> So when an include make file gets modified make restarts the original
> make file?
Correct.
> For efficiency I don't want to always create the dependencies, that's
> why I did it this way.
I don't understand what you mean by this... for ef
So when an include make file gets modified make restarts the original make
file?
For efficiency I don't want to always create the dependencies, that's why I
did it this way. Is there anyway to disable remaking?
On Wed, Sep 23, 2015 at 12:13 PM, Paul Smith wrote:
> On Wed, 2015-09-23 at 13:06 -0
On Wed, 2015-09-23 at 13:06 -0400, Mike Shal wrote:
> Though normally you don't want to include .d files as targets in your
> Makefile. Just generate them as a side-effect of compilation with -MMD
> or whatever in gcc and then include them, and you can avoid the whole
> issue.
For an example and d
On Wed, Sep 23, 2015 at 12:57 PM, John Westing wrote:
> I made a typo in my previous email: The following make file duplicates the
> problem, the one in the previous email does not:
>
> a.d:
> gcc -m32 -MM -o $@ a.c
> sed 's!a.o!$@ a.o!' --in-place $@
>
> a.o:
> gc
I made a typo in my previous email: The following make file duplicates the
problem, the one in the previous email does not:
a.d:
gcc -m32 -MM -o $@ a.c
sed 's!a.o!$@ a.o!' --in-place $@
a.o:
gcc -c -m32 -o $@ a.c
all: a.d a.o
-include a.d
Any ideas?
On
I originally posted this problem here:
http://stackoverflow.com/questions/32742321/make-unexpected-behavior-with-dependencies-and-include-statement
Here's my problem:
I have the following Makefile:
a.d:
gcc -m32 -MM -o $@ a.c
sed 's!a.o!$@ a.o!' --in-place $@
a.o:
Update of bug #45476 (project make):
Item Group: Bug => Enhancement
Assigned to:None => eliz
Triage Status:None => Need Info
_
Update of bug #45838 (project make):
Status:None => Fixed
Open/Closed:Open => Closed
Fixed Release:None => SCM
Triage Status:
13 matches
Mail list logo
