Attached is a small patch to Configure.pl that "touches" platform.h and platform.c so that Configure.pl isn't run a second time when you do a make. This doesn't fix Win32's build problems but it makes it less annoying trying to figure out the cause of them.
Jason. ----- Original Message ----- From: "Lee Berger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, December 31, 2001 12:51 AM Subject: recent win32 build errors > 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] > > > >
utime.patch
Description: Binary data
