Christopher Faylor wrote: > On Sat, Feb 15, 2003 at 09:19:05PM -0000, Max Bowsher wrote: >> Yes, in an ideal world, configure would deal with this - but unless >> you have a better idea, the only way I can think of dealing with it >> is to copy the problem header to the compilation directory, parse >> out the problem declaration somehow, and modify the compiler >> invocations with an additional -I option. Messy and fragile. > > Wow, are you related to Rube Goldberg? > > #define mempcpy foo_mempcpy > #include <string.h> > #undef mempcpy
Ok, I feel stupid :-) >> So, when fixing the problem is orders of magnitude easier than >> making a workaround, it's easy to see which will happen! :-) > > This is *not* a workaround. This is making configury work for what > it was designed to do. One could say that configury is a workaround :-) You are, of course, correct that this is one more class of weirdness that configury could be enhanced to deal with. I was just commenting that I didn't think it was particulary likely to happen. > In this case, the whole point of configuration scripts is to work > around OS build environment differences. "In an ideal world" is > exactly what configure is not supposed to assume. I agree. What I meant was: In an ideal world someone would make the relevant improvements to configury. > Of course we're going to fix cygwin. I just checked in a fix. Great! > I assume this will probably be the end of it since no one will go to > the effort of trying to fix libintl's configury Yes, that's what I was trying to say. Seems I didn't convey my point very well. Max. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/