> So, the project. Someone needs to go through the configure procedureand the headers and throw a PARROT_ prefix in front of all the HAS_ defines we define, so we can avoid this problem.
I have a look at the configure procedure and didn't find anything that could have set up something like HAS_STDLIB_H.
While configuring we generate 3 header files: config.h, has_header.h, feature.h.
In the config.h file nearly every define has the PARROT_ prefix and others that don't have it are harmless unless DEFAULT_SIZE.
In has_header.h we define a good deal of HAS_HEADER_* defines. I judge those could be worthy of the PARROT_ prefixing. And if I judge correctly we will have to make alternations in the following files, too:
Works for me.
Next. In feature.h or, rather, in the feature.pl script we try (when possible) to define the following HAS_:
HAS_POSIX_MEMALIGN HAS_SOME_MEMALIGN HAS_MEMALIGN HAS_JIT_FCOMIP HAS_SIGACTION HAS_SETITIMER HAS_SOME_SYS_TIMER HAS_SETENV HAS_UNSETENV
Prefixing those could cause a monstrous number of changes in other files. And I can hardly believe that any of those could do any harm.
Well... the problem we may run into is if we end up yanking in headers that define those differently than we do, which is what started this in the first place.
We're in the inenviable position of potentially including almost anything, so we're vulnerable to all the bizarre ways that people define things and use what they've defined, which is why I want to get defensive about this before we get bitten.
--
Dan--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
