FS#22279 - [colorgcc] Remove "/bin" symlinks
Attached to Project:
Community Packages
Opened by Lukas Fleischer (lfleischer) - Sunday, 02 January 2011, 17:41 GMT
Last edited by Eric Belanger (Snowman) - Monday, 10 January 2011, 00:54 GMT
Opened by Lukas Fleischer (lfleischer) - Sunday, 02 January 2011, 17:41 GMT
Last edited by Eric Belanger (Snowman) - Monday, 10 January 2011, 00:54 GMT
|
Details
Description:
Imho, creating gcc related symlinks in "/bin" automagically is not the Arch way of doing it. This mostly takes away the user's freedom of choice whether to use gcc/colorgcc when compiling stuff or not (by default, users should be able to run default gcc and invoke colorgcc manually, if desired). It furthermore depends on having "/bin" before "/usr/bin" in your "$PATH" environment which should not be assumed (it's not the case for me, e.g.). I'd suggest removing the `ln -s` commands at the end of the build() function and displaying an installation message proposing to either add a colorgcc alias or create the symlinks/fixing "$PATH" manually, instead. Additional info: * colorgcc 1.3.2-6 |
This task depends upon
Closed by Eric Belanger (Snowman)
Monday, 10 January 2011, 00:54 GMT
Reason for closing: Fixed
Additional comments about closing: fixed in colorgcc-1.3.2-7.
The .install file suggest to export the path in .bash_profile instead of .bashrc not to get multiple /usr/lib/colorgcc/bin entries in the path.
Monday, 10 January 2011, 00:54 GMT
Reason for closing: Fixed
Additional comments about closing: fixed in colorgcc-1.3.2-7.
The .install file suggest to export the path in .bash_profile instead of .bashrc not to get multiple /usr/lib/colorgcc/bin entries in the path.
FS#22187might be related to this btw.FS#22187. Gentoo puts the symlinks in /usr/lib/colorgcc/bin and has a post install message. I'll check what other distro do and decide what the best solution is.Aliases or an "export CC=/usr/bin/colorgcc" only works when calling gcc explicitely. They don't work when make is used unless you use "make CC=/usr/bin/colorgcc". As make is used in most cases, especially in PKGBUILD, and because most users who have colorgcc installed would want to use it, I'll probably keep the symlinks but move them to /usr/lib/colorgcc/bin like Gentoo does. Having them in a non-standard directory will ensure that they remain first in the PATH and it will be easier to enable and disable coloring.
I'm also thinking about adding a /etc/profile.d/colorgcc.sh that will update the PATH to have gcc coloring by default like the previous behavior (as we'll keep the symlinks). If not, there'll be a post-install message to add /usr/lib/colorgcc/bin to the PATH.
Adding "CC=/usr/bin/colorgcc CXX=/usr/bin/colorgcc" to MAKEFLAGS in /etc/makepkg.conf gives colors when makepkg is used. So it could work without the symlinks but the setup might be messy:
-Aliasing gcc/g++ or exporting CC/CXX for explicit gcc/g++ usage.
-Aliasing make to "make CC=/usr/bin/colorgcc CXX=/usr/bin/colorgcc" for explicit make usage.
-Adding "CC=/usr/bin/colorgcc CXX=/usr/bin/colorgcc" to MAKEFLAGS in /etc/makepkg.conf for makepkg usage.
I just noticed that ccache and distcc use a /usr/lib/$pkgname/bin. So it's an extra incentive to keep (and move) the symlinks to /usr/lib/colorgcc/bin and add a post install message about adding it to PATH.