* Re: gobject-introspection typelibs and shared libraries
@ 2015-01-17 9:46 Federico Beffa
2015-01-17 10:15 ` 宋文武
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Federico Beffa @ 2015-01-17 9:46 UTC (permalink / raw
To: andreas, Guix-devel, Ludovic Courtès, Mark H. Weaver
>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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gobject-introspection typelibs and shared libraries
2015-01-17 9:46 gobject-introspection typelibs and shared libraries Federico Beffa
@ 2015-01-17 10:15 ` 宋文武
2015-01-17 10:40 ` ‘gcc’ vs. ‘cc’ Ludovic Courtès
2015-01-17 12:02 ` gobject-introspection typelibs and shared libraries Andreas Enge
2 siblings, 0 replies; 10+ messages in thread
From: 宋文武 @ 2015-01-17 10:15 UTC (permalink / raw
To: Federico Beffa, andreas, Guix-devel, Ludovic Courtès,
Mark H. Weaver
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* ‘gcc’ vs. ‘cc’
2015-01-17 9:46 gobject-introspection typelibs and shared libraries Federico Beffa
2015-01-17 10:15 ` 宋文武
@ 2015-01-17 10:40 ` Ludovic Courtès
2015-01-17 10:44 ` John Darrington
2015-01-17 12:02 ` Federico Beffa
2015-01-17 12:02 ` gobject-introspection typelibs and shared libraries Andreas Enge
2 siblings, 2 replies; 10+ messages in thread
From: Ludovic Courtès @ 2015-01-17 10:40 UTC (permalink / raw
To: Federico Beffa; +Cc: Guix-devel
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ‘gcc’ vs. ‘cc’
2015-01-17 10:40 ` ‘gcc’ vs. ‘cc’ Ludovic Courtès
@ 2015-01-17 10:44 ` John Darrington
2015-01-17 10:47 ` Ludovic Courtès
2015-01-17 12:02 ` Federico Beffa
1 sibling, 1 reply; 10+ messages in thread
From: John Darrington @ 2015-01-17 10:44 UTC (permalink / raw
To: Ludovic Courtès; +Cc: Guix-devel, Federico Beffa
[-- 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 --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ‘gcc’ vs. ‘cc’
2015-01-17 10:44 ` John Darrington
@ 2015-01-17 10:47 ` Ludovic Courtès
0 siblings, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2015-01-17 10:47 UTC (permalink / raw
To: John Darrington; +Cc: Guix-devel, Federico Beffa
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ‘gcc’ vs. ‘cc’
2015-01-17 10:40 ` ‘gcc’ vs. ‘cc’ Ludovic Courtès
2015-01-17 10:44 ` John Darrington
@ 2015-01-17 12:02 ` Federico Beffa
2015-01-17 16:27 ` Ludovic Courtès
1 sibling, 1 reply; 10+ messages in thread
From: Federico Beffa @ 2015-01-17 12:02 UTC (permalink / raw
To: Ludovic Courtès; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gobject-introspection typelibs and shared libraries
2015-01-17 9:46 gobject-introspection typelibs and shared libraries Federico Beffa
2015-01-17 10:15 ` 宋文武
2015-01-17 10:40 ` ‘gcc’ vs. ‘cc’ Ludovic Courtès
@ 2015-01-17 12:02 ` Andreas Enge
2015-01-18 9:39 ` Federico Beffa
2 siblings, 1 reply; 10+ messages in thread
From: Andreas Enge @ 2015-01-17 12:02 UTC (permalink / raw
To: Federico Beffa; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: ‘gcc’ vs. ‘cc’
2015-01-17 12:02 ` Federico Beffa
@ 2015-01-17 16:27 ` Ludovic Courtès
0 siblings, 0 replies; 10+ messages in thread
From: Ludovic Courtès @ 2015-01-17 16:27 UTC (permalink / raw
To: Federico Beffa; +Cc: Guix-devel
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’.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gobject-introspection typelibs and shared libraries
2015-01-17 12:02 ` gobject-introspection typelibs and shared libraries Andreas Enge
@ 2015-01-18 9:39 ` Federico Beffa
2015-01-18 13:16 ` Andreas Enge
0 siblings, 1 reply; 10+ messages in thread
From: Federico Beffa @ 2015-01-18 9:39 UTC (permalink / raw
To: Andreas Enge; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: gobject-introspection typelibs and shared libraries
2015-01-18 9:39 ` Federico Beffa
@ 2015-01-18 13:16 ` Andreas Enge
0 siblings, 0 replies; 10+ messages in thread
From: Andreas Enge @ 2015-01-18 13:16 UTC (permalink / raw
To: Federico Beffa; +Cc: Guix-devel
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-01-18 13:16 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-01-17 9:46 gobject-introspection typelibs and shared libraries Federico Beffa
2015-01-17 10:15 ` 宋文武
2015-01-17 10:40 ` ‘gcc’ vs. ‘cc’ Ludovic Courtès
2015-01-17 10:44 ` John Darrington
2015-01-17 10:47 ` Ludovic Courtès
2015-01-17 12:02 ` Federico Beffa
2015-01-17 16:27 ` Ludovic Courtès
2015-01-17 12:02 ` gobject-introspection typelibs and shared libraries Andreas Enge
2015-01-18 9:39 ` Federico Beffa
2015-01-18 13:16 ` Andreas Enge
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.