hello! after seeing a rash of win32 build problems, i decided to look into what is going on. one problem i noticed in the emails was Configure.pl was being run twice. once by the user (as expected), and once by nmake. the reason is quiet cute:
when Configure.pl is run, it copies platforms/win32.h to include/parrot/platform.h. Makefile.in has a rule that sets Configure.pl as a dependency to $(STICKY_FILES) ... and platform.h is a member of the $(STICKY_FINGERS) macro. well, Configure.pl's timestamp is newer than win32.h! therefore, nmake will quiet understandably run Configure.pl every time. Configure.pl should forciably touch any file it copies since that copies the file timestamps too. for my testing purpopses, i just removed the dependency in Makefile.in and nmake was happy. that brings me to the next problem: string.c. there are a slew of compile errors in this file, and it all is based on pointer math on void pointers. for example, STRING has a void* bufstart member, and various functions (like string_make) try to do pointer math with it. void pointers have no size; therefore, pointer math won't work. visual c++ enforces this, and i'm a little surprised that gcc doesn't. i guess it just treats it as a char*? everything else seems to compile fine. there are a few compiler warnings due to some functions not returning values (most notiably some files in the classes directory). i'll see about working up a patch tomorrow, but a few questions for the parrot code police. what is the best way to touch a file from inside of perl? also, what is the prefered way of handling the void pointers? casting to char*? some other typedef? change STRING::bufstart from a void* to a char*? ...etc... -lee berger [EMAIL PROTECTED]
