From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EX30w-0004yG-DP for garchives@archives.gentoo.org; Tue, 01 Nov 2005 20:45:50 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA1KjRNP017822; Tue, 1 Nov 2005 20:45:27 GMT Received: from hermes.orakel.ods.org (dsl67-66.fastxdsl.nl [62.251.66.67]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA1KjRsm004348 for ; Tue, 1 Nov 2005 20:45:27 GMT Received: from aphrodite.orakel.ods.org ([172.17.2.15]) by hermes.orakel.ods.org with esmtps (TLSv1:AES256-SHA:256) (Exim 4.54) id 1EX30Y-0005lk-S2 for gentoo-osx@lists.gentoo.org; Tue, 01 Nov 2005 21:45:27 +0100 Message-ID: <4367D3E6.9060707@gentoo.org> Date: Tue, 01 Nov 2005 21:45:26 +0100 From: Grobian Organization: Gentoo Foundation User-Agent: Thunderbird 1.4.1 (Macintosh/20051006) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-osx@gentoo.org Reply-to: gentoo-osx@lists.gentoo.org MIME-Version: 1.0 To: gentoo-osx@lists.gentoo.org Subject: Re: [gentoo-osx] The road ahead? References: <20051030104901.GA15227@gentoo.org> <376467D8-BCFC-4A3C-9512-1AD1C32CB00B@gentoo.org> <20051101003258.GB10657@nightcrawler> <65C7CF99-1E15-49EE-85F2-E08AC12CD177@gentoo.org> <96c9d6a80511011216t604df16ar38139a628ce1cbeb@mail.gmail.com> <4367CE67.4070308@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Scanned: by hermes.orakel.ods.org (Exim Exiscan) using SpamAssassin and ClamAV X-Archives-Salt: e27bf85b-0823-475e-a685-258994f02252 X-Archives-Hash: 871ec59aba05016deaa9b802c1cb70bc Kito wrote: > > On Nov 1, 2005, at 2:21 PM, Grobian wrote: > >> I'm also happy to see this way as an option at least. I don't have >> good arguments yet, but I feel there's more in it somehow. >> >> On the other hand, (turning my head over to *our* glep42) it imposes a >> problem that needs to be addressable somehow by having the handles to >> dynamically do the right things depending on apple/gnu cc-suite, if >> you get what I mean. > > Wouldn't extending tc_get* be sufficient? Probably, but at the moment we already make the wrong assumption of doing: #ifdef __APPLE__ #include #else #include #endif and then calling it a darwin patch. It's an apple patch basically, but I don't know the darwin counterpart, if it would exist. What I want to say, is that not only do we need to have the right handles to get the data we need, we also need the right methods (maybe even configure checks?) to do the right things depending on another compiler/linker. Upstream uses __APPLE__ as well. We can't expect upstream to have support for Gentoo's setup with standard compiler/linker, so if we would like to support that I think we should consider using conditionals again and/or maybe override some defines the hard way to get what we want. Conclusion at my side of the story is that going the way of using (or immitating) Apple's build tools is the one of least resistance for now. -- Fabian Groffen Gentoo for Mac OS X Project -- Interim Lead -- gentoo-osx@gentoo.org mailing list