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 1EX3Dx-0005qz-Me for garchives@archives.gentoo.org; Tue, 01 Nov 2005 20:59:18 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id jA1KwsB1002120; Tue, 1 Nov 2005 20:58:54 GMT Received: from poober.local (cpe-24-27-15-174.austin.res.rr.com [24.27.15.174]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id jA1KwrNA028955 for ; Tue, 1 Nov 2005 20:58:54 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by poober.local (Postfix) with ESMTP id 49F4F103F61 for ; Tue, 1 Nov 2005 14:58:40 -0600 (CST) 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 (Apple Message framework v746.2) In-Reply-To: <4367D3E6.9060707@gentoo.org> 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> <4367D3E6.9060707@gentoo.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8C23775B-5756-446D-AB8D-6FC5ADE5103F@gentoo.org> Content-Transfer-Encoding: 7bit From: Kito Subject: Re: [gentoo-osx] The road ahead? Date: Tue, 1 Nov 2005 14:58:38 -0600 To: gentoo-osx@lists.gentoo.org X-Mailer: Apple Mail (2.746.2) X-Archives-Salt: 977d6ff3-0f27-42d4-a66b-c34d7d4b4d11 X-Archives-Hash: cca6053e23a076accb1dbd8a0f20a59a On Nov 1, 2005, at 2:45 PM, Grobian wrote: > > > 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. Its the same on darwin. Remember, the saying is 'Never ever try to determine if you are on Darwin or OS X, just check for functionality". The above example is fine, however this would obviously not be: #ifdef __APPLE__ #include #endif As this blindly assumes the proprietary frameworks are available. Anyway, I suppose custom defines are always an option too, though I'm not sure its really warranted at this point... > > 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. The linker will always be the same for the foreseeable future on any Darwin/OS X system, the compiler can and will change however...I really would't be too surprised to see them start shipping ICC at some point... > 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. Yeah, pretty much my same thought. The big advantage, is since we can build from source unlike when relying on Xcode, we can add our own goodies to make ebuild maintaining a little easier... the -Wl,-z,now situation comes to mind, patching our ld to deal with those options would be a far cleaner solution than having to fight it out on -dev@ trying to get linux folks to change their ways... --Kito -- gentoo-osx@gentoo.org mailing list