Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge <address@hidden> 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 <address@hidden> 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