%% 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
%% "Parkes, Lloyd" <[EMAIL PROTECTED]> writes:
pl> build.sh.in uses a replacement variable called @REMOTE@ to select
pl> which of remote-*.c should be used. This seems to be obsolete with
pl> Makefile.in using @USE_CUSTOMS_FALSE@ and @USE_CUSTOMS_TRUE@
pl> instead.
Hi; this bug has been f
Hi there,
build.sh.in uses a replacement variable called @REMOTE@ to select which of
remote-*.c should be used. This seems to be obsolete with Makefile.in using
@USE_CUSTOMS_FALSE@ and @USE_CUSTOMS_TRUE@ instead.
For some of us build.sh is still very handy.
Thanks,
Lloyd Parkes
11 matches
Mail list logo
