moin Hans, moin list, On 2009-04-20 02:10:17, Hans-Christoph Steiner <[email protected]> appears to have written: > On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote: >> moin Hans, >> On 2009-04-18 06:57:53, Hans-Christoph Steiner <[email protected]> appears to >> have written: >>> >>> The bad news is that it seems that my bad diagnosis led you on a wide >>> goose chase thru the pain of Windows development. >> >> It may or may not have been a bad diagnosis (although it certainly was a >> pain ;-) -- I still haven't verified the former, since I don't use (or >> understand) all of the auto-build scripts. I'm still kinda hoping >> IOhannes might make some headway there... > > You don't really need to understand the auto-build scripts, all that > needs to work is this: > > cd pure-data/externals > make moocow > make moocow_install
yup, I've understood that bit (and the motivations, I think). I meant that since the problems arising in 'make moocow' appear to have been *due to* clever & fiendish details of earlier scripts (e.g. use of rsync rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have behooved me to have understood those scripts better (e.g. at all)... >>> Apparently, >>> string2any and friends are still not getting built. In fact all of the >>> 'moocow' is empty on Windows. This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale): configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -mms-bitfields \ -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \ -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c >&5 <command line>:4:1: macro names must be identifiers <command line>:5:1: macro names must be identifiers <command line>:6:1: macro names must be identifiers <command line>:7:1: macro names must be identifiers configure:2704: $? = 1 configure:2742: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "locale" | #define PACKAGE_TARNAME "locale" | #define PACKAGE_VERSION "0.02-1" | #define PACKAGE_STRING "locale 0.02-1" | #define PACKAGE_BUGREPORT "[email protected]" | #define PACKAGE "locale" | #define VERSION "0.02-1" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2749: error: C compiler cannot create executables ... newline escapes in the gcc call added post-hoc for legibility. The above call works fine (creating a.exe) by hand on the build farm win32 machine with "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" prepended to PATH, so I can't grok where things might be going wrong, much less what the "macro names must be identifiers" errors are all about -- assumedly some of the '-D' flags are giving me grief, but since I can't reproduce the error, I can't tell which ones or what to do about it. Anyone have any ideas? I can't use rdesktop currently, since it's telling me I'd have to kick out another user (pd). >> In a related question, should the auto-build process for the win32 >> build-farm machine be trying to build everything from the LIB_TARGETS >> variable in externals/Makefile? If so, then I must be being pretty >> dense, because I can't see where my builds are getting called (I see >> install calls, but no configuration or compilation), much less where >> they might be failing... > > You are correct. Search for 'moocow_install:' in externals/Makefile. > That's where its being called. Yes, right; but I couldn't see (until the rsync fix/hack was applied) where the 'moocow' target was getting called, thus recursing into externals/moocow/extended. That's showing up now, so no worries. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [email protected] -Lubarsky's Law of Cybernetic Entomology _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
