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
%% 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 fixed in
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
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 packaged
%% 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 modules
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 only
%% 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 makefiles,
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
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 allow
