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,
19 matches
Mail list logo
