Re: gobject-introspection typelibs and shared libraries

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote:
>> If there’s consensus to install the symlink, that’s fine with me (if we
>> take that route, I would also suggest submitting a patch upstream so GCC
>> installs the symlink.)
>
>I am not in favour of adding such a symlink on our own and would rather
>keep with the standard builds as we usually do when there is no compelling
>reason to do otherwise.

That's interesting.

Consider that:

* such a symlink would have spared much frustration to Mark (see
earlier posts in this thread).

* It is likely that the update of 'gobject-introspection' to a newer
version would not have caused problems (see earlier posts in this
thread and https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00196.html).
And, from Ludovic's comment: "So far we’ve resisted the temptation.
...", I understand that there are a few other packages which would
benefit.

* Up to now nobody could point out any *technical* drawback. (And if
we find one later, we can always revert.)

Even if an action if beneficial to, say, 1 in 100 packages without
drawbacks to the other ones and the fix of that single package is
easy, it is still worth doing. I do not see a large number of people
contributing to this project. It is therefore important to minimize
the likelihood of a required manual intervention to fix problems.
Maintaining 1000's of software packages is time consuming!

It would be the *GUIX project* the one who would benefit if decisions
would be taken based on technical arguments and merits instead of
feelings or the mood of the day.

Fede

Re: gobject-introspection typelibs and shared libraries

[宋文武]

Federico Beffa <beffa@ieee.org> writes:

>>On Thu, Jan 15, 2015 at 10:42:42PM +0100, Ludovic Courtès wrote:
>>> If there’s consensus to install the symlink, that’s fine with me (if we
>>> take that route, I would also suggest submitting a patch upstream so GCC
>>> installs the symlink.)
>>
>>I am not in favour of adding such a symlink on our own and would rather
>>keep with the standard builds as we usually do when there is no compelling
>>reason to do otherwise.
>
> That's interesting.
>
> Consider that:
>
> * such a symlink would have spared much frustration to Mark (see
> earlier posts in this thread).
How about set $CC to 'gcc' in our 'gnu-build-system'?
>
> * It is likely that the update of 'gobject-introspection' to a newer
> version would not have caused problems (see earlier posts in this
> thread and https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00196.html).
> And, from Ludovic's comment: "So far we’ve resisted the temptation.
> ...", I understand that there are a few other packages which would
> benefit.
>
> * Up to now nobody could point out any *technical* drawback. (And if
> we find one later, we can always revert.)
>
> Even if an action if beneficial to, say, 1 in 100 packages without
> drawbacks to the other ones and the fix of that single package is
> easy, it is still worth doing. I do not see a large number of people
> contributing to this project. It is therefore important to minimize
> the likelihood of a required manual intervention to fix problems.
> Maintaining 1000's of software packages is time consuming!
>
> It would be the *GUIX project* the one who would benefit if decisions
> would be taken based on technical arguments and merits instead of
> feelings or the mood of the day.
>
> Fede

‘gcc’ vs. ‘cc’

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> * such a symlink would have spared much frustration to Mark (see
> earlier posts in this thread).

Again, there have been few cases where this has caused problems (on the
order of 10-20 packages out of 1000.)  I agree it’s better if we can
avoid these problems altogether, but it’s not a real threat either.  ;-)

What about doing this:

  1. Someone (Fede? :-)) opens a bug against GCC at
     <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
     link.

  2. In the next core-updates, we introduce (setenv "CC" "gcc"), as
     suggested by 宋文武, which is the least intrusive solution.  It
     will fix most uses I think, but not all (for instance, GLEW has
     “CC = cc” hard-coded in its Makefile, so it will still need
     patching; this is fine, IMO.)

WDYT?

Ludo’.

Re: ‘gcc’ vs. ‘cc’

[John Darrington]

[-- Attachment #1: Type: text/plain, Size: 1381 bytes --]

On Sat, Jan 17, 2015 at 11:40:30AM +0100, Ludovic Courtès wrote:
     Federico Beffa <beffa@ieee.org> skribis:
     
     > * such a symlink would have spared much frustration to Mark (see
     > earlier posts in this thread).
     
     Again, there have been few cases where this has caused problems (on the
     order of 10-20 packages out of 1000.)  I agree it’s better if we can
     avoid these problems altogether, but it’s not a real threat either.  ;-)
     
     What about doing this:
     
       1. Someone (Fede? :-)) opens a bug against GCC at
          <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
          link.
     
       2. In the next core-updates, we introduce (setenv "CC" "gcc"), as
          suggested by 宋文武, which is the least intrusive solution.  It
          will fix most uses I think, but not all (for instance, GLEW has
          “CC = cc” hard-coded in its Makefile, so it will still need
          patching; this is fine, IMO.)
     
     WDYT?
     

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.
     

-- 
PGP Public key ID: 1024D/2DE827B3 
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: ‘gcc’ vs. ‘cc’

[Ludovic Courtès]

John Darrington <john@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.

Maybe the symlink is better, then.

Ludo’.

Re: ‘gcc’ vs. ‘cc’

[Federico Beffa]

On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>   1. Someone (Fede? :-)) opens a bug against GCC at
>      <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
>      link.

Given that gcc is also used on many proprietary UNIX systems, in my
opinion, handling of the cc name is a system thing, not a gcc one.

Fede

Re: ‘gcc’ vs. ‘cc’

[Ludovic Courtès]

Federico Beffa <beffa@ieee.org> skribis:

> On Sat, Jan 17, 2015 at 11:40 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>>   1. Someone (Fede? :-)) opens a bug against GCC at
>>      <https://gcc.gnu.org/bugzilla/> suggesting to install the ‘cc’
>>      link.
>
> Given that gcc is also used on many proprietary UNIX systems, in my
> opinion, handling of the cc name is a system thing, not a gcc one.

Right, makes sense.

Ludo’.

Re: gobject-introspection typelibs and shared libraries

[Andreas Enge]

On Sat, Jan 17, 2015 at 10:46:35AM +0100, Federico Beffa wrote:
> It would be the *GUIX project* the one who would benefit if decisions
> would be taken based on technical arguments and merits instead of
> feelings or the mood of the day.

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.

On Sat, Jan 17, 2015 at 11:47:20AM +0100, Ludovic Courtès wrote:
> John Darrington <john@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
would also be okay. But if we go for the latter, I think you should bring
it up with the gcc project first.

Andreas

Re: gobject-introspection typelibs and shared libraries

[Federico Beffa]

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

Re: gobject-introspection typelibs and shared libraries

[Andreas Enge]

On Sun, Jan 18, 2015 at 10:39:52AM +0100, Federico Beffa wrote:
> On Sat, Jan 17, 2015 at 1:02 PM, Andreas Enge <andreas@enge.fr> wrote:
> > 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

Yes, that was a good point (which crossed my message).

Andreas