On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge <andr...@enge.fr> 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ès wrote: >> John Darrington <j...@darrington.wattle.id.au> skribis: >> > If we choose to do that, then for consistency we should also >> > do (setenv "LEX" "flex") and (setenv "YACC" "bison") Possibly a few >> > others too. >> Bah, this suggests that it’s 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
