Mail Archives: cygwin-apps/2000/12/21/16:36:37
I inadvertently sent this to Earnie privately rather than to the list.
On Thu, Dec 21, 2000 at 06:24:31AM -0800, Earnie Boyd wrote:
>--- Christopher Faylor <cgf AT redhat DOT com> wrote:
>> On Wed, Dec 20, 2000 at 07:46:47PM -0800, Earnie Boyd wrote:
>> >--- Christopher Faylor <cgf AT redhat DOT com> wrote:
>> >> On Wed, Dec 20, 2000 at 04:48:41PM -0800, Sammartino, Ryan wrote:
>> >> >If you look at a slightly larger slice of the code
>> >> >than diff -c provides, you'll see that this whole thing
>> >> >is wrapped in a "#ifdef GCC_IS_NATIVE" directive, which is
>> >> >set near the top of default.c:
>> >> >
>> >> >/* Define GCC_IS_NATIVE if gcc is the native development environment on
>> >> > your system (gcc/bison/flex vs cc/yacc/lex). */
>> >> >/* CYGNUS LOCAL: or __CYGWIN__ */
>> >> >#if defined(__MSDOS__) || defined(__CYGWIN__)
>> >> >#define GCC_IS_NATIVE
>> >> >#endif
>> >> >
>> >> >
>> >> >so it does seem to be a "cygnus only" thing.
>> >> Sorry, I don't understand your logic. If GCC_IS_NATIVE, surely g++
>> >> either be the default c++ compiler or someone had a reason for not
>> >> making that the case. AFAICT, you are modifying a section of make that
>> >> is untouched by Cygnus/Red Hat. It's under the control of a define
>> >> which can be set in non-Cygwin conditions. Roland McGrath obviously had
>> >> a reason for doing this. If it was wrong, then the make maintainer
>> >> (psmith AT gnu DOT org) should apprised of that fact.
>>>And possibly the correct solution is to remove the `||
>>>defined(__CYGWIN__)' in this instance. The probable case here is that
>>>back in version x a patch was submitted that took effect in version y
>>>so that there is no Cygwin specific change anymore. It would be a
>>>Cygwin package maintainers job to see that such code patches are
>>>submitted back to the source maintainer.
>>If you are going to trust the cygwin package maintainer to make the
>>right decision, then, his decision is that the GNU maintainer of the
>>file in question should be notified. As far as the comment in the file
>>is concerned, Cygwin is doing the right thing.
>>I am not particularly bothered by the default CXX and I don't see any
>>reason why I should be burdened with going to the effort of trying to
>>champion a fix that I have little interest in. I don't have any
>>special relationship with the make maintainer which would enable me to
>>receive special consideration.
>Gees, calm down Chris. I was speaking generalities for the benefit of
>the archive. I also just realized that you consider yourself to be the
>Cygwin package maintainer for make. I had asked this list if there was
>one, and didn't see a direct answer. I has also asked the original
>poster if he would like to become the Cygwin package maintain for make
>if there wasn't one already and he agreed to do that and submitted a
>patch. If I were you I'd relinquish it over to him and let him have at
>it and quit being hardnosed about the help.
Sorry. I wasn't closely following the discussion and didn't catch that
anyone was volunteering. I've been curtailing my mailing list duties,
especially when I see thread with a lot of back and forth with responses
from people who are mailing list veterans. However, given the
suggestion that someone could be a make maintainer, contacting the GNU
maintainer makes even more sense.
However, I'm not actually looking for a make maintainer. make has too
much cygnus-specific code in it. I'll gladly accept a helper, though.
I.e., someone to contact the GNU maintainer for specific make fixes.
Btw, if this was any other project in the world besides cygwin, the
simple idea of contacting the actual maintainer of the GNU package would
be a complete no-brainer. I find it incredible that you would consider
this "hard nosed".
- Raw text -