[PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)

[Bryan Jurish]

moin Hans, moin list,

On 2009-04-20 02:10:17, Hans-Christoph Steiner <hans at eds.org> 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 <hans at eds.org> 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 "moocow at ling.uni-potsdam.de"
| #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."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology