Wow, it was smoother than expected. I just found a missing ${OBJS} in
the make clean for binr/
I have tested this patch before commiting and found it a little bit
faster. this is 50s vs 53s on make
and 21s vs 23s with make -j 8 on my quadcore box.
On 11/02/11 21:55, Glyn Kennington wrote:
pancake wrote:
I can test the building issues in the farm.. So we now have time to break
things.
The problem is that actually the patches does not apply and some file patches
got rejected.
Yes, the same happened in my own tree when I left it for a couple of weeks,
somewhere around the sysmagic change. Since then, I've updated every few days
and not had any problems.
looks like it also works fine for building the w32 crosscompilation :)
i will test crosscompilation for android and mingw64 later, but this
should be problematic.
Thanks for the patch, it really looks cleaner now :)
The next build fix should be in r2-bindings, some people reported
problems or missconceptions
on the current configure setup.
https://twitter.com/#!/schrotthaufen/status/131787370155614209
https://twitter.com/#!/schrotthaufen/status/131771473932206080
https://twitter.com/#!/schrotthaufen/status/131417261960462337 <- python
bindings are just for 2.7, not 3.x
http://elektranox.org/r2-bindings.txt
It would be great if you can send me an updated version of the patch and meet
in the irc to discuss any of the issues if exist.
Attached.
One trivial point - I've seen both kinds of references to Makefile variables,
ie.
${HAVE_LIB_SSL}
and
$(HAVE_LIB_GMP)
Is the choice of ${ vs $( dependent on the variable name, or is it just
whatever was easiest at the time?
i tend to use parenthesis in makefiles and brackets in shellscripts, but
i think there's no difference
between them in Makefiles. But using $() in makefiles can be problematic
as long as they are used
as function callers like $(shell. ..) ..
--pancake
_______________________________________________
radare mailing list
[email protected]
http://lists.nopcode.org/listinfo.cgi/radare-nopcode.org
