From mboxrd@z Thu Jan 1 00:00:00 1970 From: Federico Beffa Subject: Re: gobject-introspection typelibs and shared libraries Date: Sun, 18 Jan 2015 10:39:52 +0100 Message-ID: References: <20150117120244.GA8583@debian> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:50265) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YCmKp-0001QA-2v for guix-devel@gnu.org; Sun, 18 Jan 2015 04:39:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YCmKn-0002rg-OV for guix-devel@gnu.org; Sun, 18 Jan 2015 04:39:55 -0500 In-Reply-To: <20150117120244.GA8583@debian> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andreas Enge Cc: Guix-devel On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge wrote: > Why do you suggest that my message was inspired by feelings or the mood > of the day? In fact, it was rather by the principles and design choices > we have made (without necessarily writing them down) in the past. > Especially with little available work power, I think it is important that= we > do not make too many modifications to the upstream packages; there are > distributions out there with a tendency to become more or less upstream > themselves... On the long run, this would be a nightmare to maintain. I guess I misunderstood a little bit your email. I think we are all on the same page on the fact that we want to minimize modifications from upstream. For the specifics of this case, I don't see any danger of becoming an upstream reference because: (i) it is not a modification of a package, but a trivial non invasive addition and (ii) many distributions (including, e.g., Debian) already have a 'cc' command pointing to 'gcc'. > > On Sat, Jan 17, 2015 at 11:47:20AM +0100, Ludovic Court=C3=A8s wrote: >> John Darrington skribis: >> > If we choose to do that, then for consistency we should also >> > do (setenv "LEX" "flex") and (setenv "YACC" "bison") Possibly a few o= thers too. >> Bah, this suggests that it=E2=80=99s a can of worms. > > I think this makes exactly my technical point above... > > Now we can and do make exceptions. About the particular issue, I do not > have very strong feelings. I fail to see why '(setenv "CC" "gcc")' > in cases where it is necessary poses major problems; but having a symlink Lets take 'gobject-introspection' as one illustrative example: we were using a version which was compiling fine without the need for $CC. Then, first Mark and then me tried to update to the latest version and suddenly many packages were not building anymore with the new version (but 'gobject-introspection' itself was still building fine). Mark temporarily gave up (I guess because he had other priorities), but I went further because I really needed the latest version to fix the absolute path of dynamic libraries referred to in typelib/gir files. To find the root cause I had to go and read the source of 'g-ir-scanner' with which I'm not at all familiar and which is made out of many files. After a while I've found that 'g-ir-scanner' looks for the environment variable CC and, if it is not defined, then it used the hard coded command 'cc' to call the C compiler. The moral of the story is that sometimes it is *difficult to find out* that you need to define CC. Given that the traditional name of the C compiler is 'cc' and not 'gcc', having that name defined could sometimes save us time. Remember that not everybody only targets the GNU C compiler. In the example above the upgrade would just have gone smooth. > would also be okay. But if we go for the latter, I think you should bring > it up with the gcc project first. I expressed my opinion on this here https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00230.html Hope this helps to clarify the reason for my suggestion. Fede