Exactly. For the way make is conceived now, once it starts building a
target it doesn't check for any other rule which have that save target. In
other words, once make goes to build foo.o, and then it executes a rule
which imports some other rules for foo.o, those rules are just ignored.
This I t
On Mon, 30 Jun 2003, Peter A. Kerzum wrote:
> Yeah, Fabio's way seem quite clean and pretty. I agree that eval should
> support include.
>
> > Sure. You specify that the other prerequisites also depend on exe-deps:
> >
> > foo: exe-deps foo.o bar.o baz.o
> > foo.o bar.o baz.o: exe-deps
> >
>
%% "Peter A. Kerzum" <[EMAIL PROTECTED]> writes:
pak> Yeah, Fabio's way seem quite clean and pretty. I agree that eval
pak> should support include.
$(eval ...) does support include.
What Fabio wants to do is declare new prerequisites inside of a
command script. That may not be possible in a
Yeah, Fabio's way seem quite clean and pretty. I agree that eval should
support include.
Sure. You specify that the other prerequisites also depend on exe-deps:
foo: exe-deps foo.o bar.o baz.o
foo.o bar.o baz.o: exe-deps
But as far as I understand make this will cause troubles if exe-deps
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Fri, 27 Jun 2003, Paul D. Smith wrote:
fa> automake uses recursive makefiles, which is something I want to
fa> avoid.
>> I wasn't suggesting automake in total, I was suggesting their dependency
>> generation style only... this is basi
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> fa> automake uses recursive makefiles, which is something I want to
> fa> avoid.
>
> I wasn't suggesting automake in total, I was suggesting their dependency
> generation style only... this is basically what's described on my
> website.
hum... I must
On Sat, 28 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> so this might be used as fall-back solution in case the make's bug
> fa> doesn't get solved.
>
> In an earlier email from you you said you were using the CVS code and
> "it worked" (or words to tha
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> so this might be used as fall-back solution in case the make's bug
fa> doesn't get solved.
In an earlier email from you you said you were using the CVS code and
"it worked" (or words to that effect, I don't have the email any
longer).
Can you
On Sat, 28 Jun 2003, Fabio Alemagna wrote:
> This is the code:
>
> define getdeplist_1
> $(eval __ALLDEPS__ += $(1)) $(foreach m,$(1),$(foreach d,$($(m)/DEPS),$(if \
> $(findstring $(d),$(__ALLDEPS__)),,$(call getdeplist_1,$(d)
> endef
This one is simpler and more correct (in that it doesn't a
On Fri, 27 Jun 2003, Fabio Alemagna wrote:
> Yes, that's what I thought too, however You'd agree that it would take
> time for make to accomplish that job, and perhaps there could be other
> issues, like dependency loops, which would be impossible to solve, or very
> very difficult. It seems only p
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Fri, 27 Jun 2003, Paul D. Smith wrote:
>> As pointed out before, if you do the dependency generation the way
>> automake does it (as described on my web site) you won't have any
>> of these problems.
fa> automake uses recursive makef
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> As pointed out before, if you do the dependency generation the way
> automake does it (as described on my web site) you won't have any of
> these problems.
automake uses recursive makefiles, which is something I want to avoid.
> fa> My solution (if on
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> I suggest you first either build the latest CVS code or, if you don't
> have the infrastructure for that (building from CVS requires that you
> have autoconf, automake, etc. installed already--if you don't have a
> Linux box, where these things are packag
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> This is unacceptable for VERY large projects with lots of modules
fa> and .c files belonging to those modules: say I want to build
fa> module A and B only, which don't depend on any other module; since
fa> I include ALL .d files for ALL mod
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> I know that, I've thought of it myself, but it just doesn't work
fa> for autogenerated header files: say foo.o depends on foo.h, but
fa> foo.h is autogenerated; now, make won't know about foo.h until
fa> next time it's invoked, because the
There are a couple of bugs in the $(eval ...) memory handling which
might be related to this.
I suggest you first either build the latest CVS code or, if you don't
have the infrastructure for that (building from CVS requires that you
have autoconf, automake, etc. installed already--if you don't ha
On Thu, 26 Jun 2003, Ted Stern wrote:
> Ah, you have autogenerated headers!
Not necessarily, but it may happen. I'm working on a complete and generic
build system, which understands "modules types", and on the basis of thos
types it takes some actions. It uses only make and the $(eval) function t
On Thu, 26 Jun 2003, Ted Stern wrote:
> Hi Fabio,
>
> Use the "-" prefix with your include statements, it's much simpler:
>
> -include $(DEPS)
>
> This will ignore the errors caused by a file not being found.
>
> More generally, you can make your dependency generation a lot simpler. See
> Paul
On 26 Jun 2003, Fabio Alemagna wrote:
> My goal is to have make include .d files only when they are actually
> needed, so that when make starts, it doesn't have to check whether any .c
> files (from which all the .d ones are generated) have changed, so I've
> come up with this solution:
Hi Fabio,
My goal is to have make include .d files only when they are actually
needed, so that when make starts, it doesn't have to check whether any .c
files (from which all the .d ones are generated) have changed, so I've
come up with this solution:
OBJS := ...
DEPS := ...
program: program-deps $(OB
20 matches
Mail list logo
