From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31086 invoked by alias); 13 Apr 2012 23:16:36 -0000 Received: (qmail 31074 invoked by uid 22791); 13 Apr 2012 23:16:33 -0000 X-SWARE-Spam-Status: No, hits=-5.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-we0-f175.google.com (HELO mail-we0-f175.google.com) (74.125.82.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 13 Apr 2012 23:16:19 +0000 Received: by wera1 with SMTP id a1so2537577wer.20 for ; Fri, 13 Apr 2012 16:16:17 -0700 (PDT) Received: by 10.180.100.2 with SMTP id eu2mr152307wib.1.1334358977486; Fri, 13 Apr 2012 16:16:17 -0700 (PDT) Received: from [192.168.2.99] (cpc3-cmbg8-0-0-cust629.5-4.cable.virginmedia.com. [82.6.102.118]) by mx.google.com with ESMTPS id gd4sm238409wib.6.2012.04.13.16.16.15 (version=SSLv3 cipher=OTHER); Fri, 13 Apr 2012 16:16:16 -0700 (PDT) Message-ID: <4F88B3E1.1060103@gmail.com> Date: Fri, 13 Apr 2012 23:16:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Mark Galeck (CW)" CC: Ian Lance Taylor , "gcc@gcc.gnu.org" Subject: Re: FW: is "syslimits.h" likely to change? References: <6069BF76D8010446BBF509943DB0D382010D7918EC41@HQ1-EXCH02.corp.brocade.com> <6069BF76D8010446BBF509943DB0D382010D7918EDE9@HQ1-EXCH02.corp.brocade.com> In-Reply-To: <6069BF76D8010446BBF509943DB0D382010D7918EDE9@HQ1-EXCH02.corp.brocade.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00610.txt.bz2 On 12/04/2012 16:38, Mark Galeck (CW) wrote: > Thank you Ian, hopefully I will be compatible then for a long time, as > Larry Wall would say "at least until the heat death of the Universe". > > I can't "ignore it" :) My build system cannot handle "include_next" - it > cannot handle the situation where you are finding a header file in one -I > directory, and later when you are trying to find it again, you ignore that > directory and find it in a subsequent -I directory. The system is > extremely fast, like a sports car than will only go on asphalt (standard C > and a GCC-like compiler). I'm curious why your build system even needs to handle it? The GCC version of syslimits.h is a private thing, that GCC uses just for its own purposes to adjust or override some of the definitions in the system's native syslimits.h; if you aren't using GCC, then it shouldn't matter, and if you are, then it should be automatic and transparent. And if you're generating dependencies, and using GCC as a compiler, then you should also use "gcc -M" to generate the dependencies, since it'll get them canonically right, rather than any sort of external makedepends utility. So, why does your build system care about it? cheers, DaveK