Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
llvm-defaults vs update alternatives
827 views
Skip to first unread message
Sylvestre Ledru
Jun 21, 2014, 7:00:03 PM6/21/14
to
Hello,
Currently, LLVM default binaries are managed by the llvm-defaults package
(similar to gcc-defaults).
To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
provides symlinks /usr/bin/llvm-nm to the actual binaries.
Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
snapshot).
I saw various complains from users (example:
https://bugs.launchpad.net/bugs/991493 ) to switch to the
update-alternatives mechanism. This would allow a quick and global
switch from a LLVM version to another.
I must admit that I am not sure what to do here.
I see values in both solutions.
Any opinions on the subject?
Cheers,
Sylvestre
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53A5B6E7...@debian.org
Currently, LLVM default binaries are managed by the llvm-defaults package
(similar to gcc-defaults).
To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
provides symlinks /usr/bin/llvm-nm to the actual binaries.
Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
snapshot).
I saw various complains from users (example:
https://bugs.launchpad.net/bugs/991493 ) to switch to the
update-alternatives mechanism. This would allow a quick and global
switch from a LLVM version to another.
I must admit that I am not sure what to do here.
I see values in both solutions.
Any opinions on the subject?
Cheers,
Sylvestre
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/53A5B6E7...@debian.org
Vincent Bernat
Jun 21, 2014, 7:40:01 PM6/21/14
to
❦ 21 juin 2014 18:46 +0200, Sylvestre Ledru <sylv...@debian.org> :
> Currently, LLVM default binaries are managed by the llvm-defaults package
> (similar to gcc-defaults).
> To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
> provides symlinks /usr/bin/llvm-nm to the actual binaries.
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch from a LLVM version to another.
I don't think alternatives should be used for versioning. For example,
we don't use alternatives for gcc, neither for Python. We would start
getting errors about "package X does not compile on my system" or
"module Y does cannot be compiled".
In the bug report, I just see that some upstreams didn't account for
multiple versions installed. But since it is something that exists for a
long time to choose the C compiler (and some other tools), I think they
will eventually adapt.
--
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)
> Currently, LLVM default binaries are managed by the llvm-defaults package
> (similar to gcc-defaults).
> To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
> provides symlinks /usr/bin/llvm-nm to the actual binaries.
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch from a LLVM version to another.
we don't use alternatives for gcc, neither for Python. We would start
getting errors about "package X does not compile on my system" or
"module Y does cannot be compiled".
In the bug report, I just see that some upstreams didn't account for
multiple versions installed. But since it is something that exists for a
long time to choose the C compiler (and some other tools), I think they
will eventually adapt.
--
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)
Paul Wise
Jun 21, 2014, 10:20:02 PM6/21/14
to
On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:
> Any opinions on the subject?
There is already the CC (and CXX etc) environment variable to select
> Any opinions on the subject?
the compiler, they should use that.
Build systems that ignore those environment variables are broken and
need to be fixed.
--
bye,
pabs
http://wiki.debian.org/PaulWise
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sylvestre Ledru
Jun 21, 2014, 10:30:02 PM6/21/14
to
On 21/06/2014 19:19, Paul Wise wrote:
> On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:
>
>> Any opinions on the subject?
> There is already the CC (and CXX etc) environment variable to select
> the compiler, they should use that.
I am not talking about Clang but LLVM here. LLVM itself ships some binaries:
> On Sun, Jun 22, 2014 at 12:46 AM, Sylvestre Ledru wrote:
>
>> Any opinions on the subject?
> There is already the CC (and CXX etc) environment variable to select
> the compiler, they should use that.
https://packages.debian.org/sid/amd64/llvm-3.4/filelist
About Clang, I am planning to keep on matching what is done with gcc.
>
> Build systems that ignore those environment variables are broken and
> need to be fixed.
>
Sylvestre
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Christian Hofstaedtler
Jun 22, 2014, 5:50:01 AM6/22/14
to
* Sylvestre Ledru <sylv...@debian.org> [140622 00:50]:
can no longer rely on the one specific configuration you would have
chosen ('the recommended configuration').
This basically means that you must test with all possible
configurations (LLVM versions), including those that no longer exist
in a given distribution (users may keep old packages that provide
alternative options).
The pain we've seen in the ruby packages suggests that using
update-alternatives is a bad idea if you have a 'recommended'
choice, as it will change over time and (enough) installed systems
will not follow suit.
I'd strongly recommend against using update-alternatives for
llvm-config.
C.
--
,''`. Christian Hofstaedtler <ze...@debian.org>
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-
> Currently, LLVM default binaries are managed by the llvm-defaults package
> (similar to gcc-defaults).
> To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
> provides symlinks /usr/bin/llvm-nm to the actual binaries.
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch from a LLVM version to another.
update-alternatives gives the user a choice, which implies that you
> (similar to gcc-defaults).
> To sum up, we have binaries like /usr/bin/llvm-nm-X.Y. llvm-defaults
> provides symlinks /usr/bin/llvm-nm to the actual binaries.
> Usually, I manage 3 versions of LLVM in parallel (currently, 3.3, 3.4 &
> snapshot).
>
> I saw various complains from users (example:
> https://bugs.launchpad.net/bugs/991493 ) to switch to the
> update-alternatives mechanism. This would allow a quick and global
> switch from a LLVM version to another.
can no longer rely on the one specific configuration you would have
chosen ('the recommended configuration').
This basically means that you must test with all possible
configurations (LLVM versions), including those that no longer exist
in a given distribution (users may keep old packages that provide
alternative options).
The pain we've seen in the ruby packages suggests that using
update-alternatives is a bad idea if you have a 'recommended'
choice, as it will change over time and (enough) installed systems
will not follow suit.
I'd strongly recommend against using update-alternatives for
llvm-config.
C.
--
,''`. Christian Hofstaedtler <ze...@debian.org>
: :' : Debian Developer
`. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03
`-
Vincent Danjean
Jun 23, 2014, 7:40:03 AM6/23/14
to
On 22/06/2014 11:47, Christian Hofstaedtler wrote:
> update-alternatives gives the user a choice,
My remark is not directly related to this problem (perhaps, in fact)
> update-alternatives gives the user a choice,
but update-alternatives does *not* give the user a choice.
It give the *admin* a choice.
You must be root to run update-alternatives and the choice affects
all users of a system. If you are in a multiuser environment (or
want to support such one), update-alternatives is not a solution.
I would be very pleased if update-alternatives can work for users,
at least for most packages. But it is another discussion.
A+
Vincent
--
Vincent Danjean GPG key ID 0xD17897FA vdan...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Thorsten Glaser
Jun 24, 2014, 4:50:03 AM6/24/14
to
Sylvestre Ledru <sylvestre <at> debian.org> writes:
> > Build systems that ignore those environment variables are broken and
> > need to be fixed.
> >
> Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.
Yes, but I have a GCC patch (in MirBSD) that can make such builds
> > Build systems that ignore those environment variables are broken and
> > need to be fixed.
> >
> Yes, but we have plenty of packages not honoring CC, CXX or CLFAGS.
fail, by adding a non-standard option to CFLAGS whose lack can,
depending on an environment variable, cause an error or warning.
Then just rename cc/gcc to debian-gcc and set $CC to that, so
that invoking just cc or gcc will also fail, et voilà.
I invented this patch after we had real trouble with lots of
packages not honouring CFLAGS in MirPorts, and it has made its
way via FreeWRT to OpenWrt and other systems already… (although
I did not cover the C++ case, it is easy to add).
bye,
//mirabilos
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
0 new messages