in a release which, at the time, was about to be
made. However it appears that there have no been any more releases since
then... Am I to assume that this bug will never be fixed (I read about the
patch, but I also read it doesn't work as it should)?
Fabio Ale
expected? Also, do you have any figures on the $(eval)
performances and its use in large projects? $(eval) makes things really
easy and neater, however I'm quite worried about the memory usage of make
in such cases and its performaces. Has any test been done regarding this?
emory and on whether it will be slow?
Sorry, I kow all this doesn't belong to this list... if you feel I should
email you privately, or post to another ML, please tell me.
Fabio Alemagna
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> Ok. Do you know if it still compiles on AmigaOS with ixemul (the
> fa> posix layer)? Well, I guess I can just try and see...
>
> No one has reported that it doesn
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> The first issue, is that even if it was cross compiling, it tried
> fa> to use the host's 'ar' command. I solved that by invoking
> fa> m68k-
5
#9 0x08056f2c in main (argc=4, argv=0xb604, envp=0xb618) at
main.c:1975
#10 0x4009a7f7 in __libc_start_main () from /lib/i686/libc.so.6
Any ideas?
Fabio Alemagna
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
ick would be really useful... if it worked. There's
certainly a bug in make (hell, it segfaults, so something is going wrong
for sure), so it would be nice if it could be hunted and blasted :)
The other solution that I see would be for make to provide means other
than timestamps to check whet
a new syntax for this special macro,
like for example $@(macro): $@ would not be usable in a prerequisite list
anyway, so using it like that is perfectly possible, I think.
Fabio Alemagna
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
ojects/make and go to the
> bug tracking page, then pick the "Fixed in Release" report, then choose
> "CVS" as the release. This will show you all the bugs that have been
> fixed in CVS but not released yet. There are a few about $(eval ...).
Well, a
'm going away from that way of doing dependencies, I certainly don't want
to go back to it. Anyway, I'm pointing out a bug which needs to be solved
anyway.
Fabio Alemagna
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
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 di
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 (
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
dn't ALWAYS work, leading to segfaults. I suspect these
segfaults and the general malfunctioning are due to the fact that make
doesn't take into consideration that such an $(eval) construct might be
used that way. I'm sure I hit an "hidden" and not foreseen feature of
$(eval), which should be supported though, so to be consistent with the
general $(eval) semantics.
Fabio Alemagna
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make
if you're interested I can give you
you some example code, and explain how does that work. Would be good if we
could discuss this on an ML, so that other people who are interested may
join the discussion.
Fabio Alemagna
PS: yes Paul,
This is not so much of a Make problem, but rather of the globbling
library it uses. However, since Make is affected, I thought I'd post
here about my findings to see whether someone else noticed this issue
and whether someone is willing to take a look at the library :-)
Say we are in a directory w
)
Regards,
Fabio Alemagna
-- Forwarded message ------
From: Fabio Alemagna <[EMAIL PROTECTED]>
Date: Sat, 5 Feb 2005 02:43:00 +0100
Subject: Globbing broken
To: bug-make@gnu.org
This is not so much of a Make problem, but rather of the globbling
library it uses. However, since Mak
The variable would have a special bit set so that the various
functions working on lists would know that they need to look for a NUL
char rather than for a space in order to delimit words.
Is there anything that doesn't wouldn't make this a viable option?
Regards,
Fabio Alemagna
_
18 matches
Mail list logo
