Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 01/13/2020 06:20 AM, Vít Ondruch wrote:
> 
> Dne 11. 01. 20 v 5:46 Tom Stellard napsal(a):
>> On 01/08/2020 11:28 PM, Miro Hrončok wrote:
>>> On 08. 01. 20 23:47, Tom Stellard wrote:
 I suspect that if I can find some way to set the CC and CXX environment
 variables for all builds, not just ones using autoconf, cmake or meson,
 that might help cut down on the number of packages that still use gcc.
 I'm just not quite sure how to implement this yet, but I'm looking into
 it.
>>> /usr/lib/rpm/macros has:
>>>
>>> %___build_pre\
>>>   RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
>>>   RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
>>>   RPM_OPT_FLAGS=\"%{optflags}\"\
>>>   RPM_LD_FLAGS=\"%{?build_ldflags}\"\
>>>   RPM_ARCH=\"%{_arch}\"\
>>>   RPM_OS=\"%{_os}\"\
>>>   RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
>>>   export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
>>> RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS\
>>>   RPM_DOC_DIR=\"%{_docdir}\"\
>>>   export RPM_DOC_DIR\
>>>   RPM_PACKAGE_NAME=\"%{NAME}\"\
>>>   RPM_PACKAGE_VERSION=\"%{VERSION}\"\
>>>   RPM_PACKAGE_RELEASE=\"%{RELEASE}\"\
>>>   export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE\
>>>   LANG=C\
>>>   export LANG\
>>>   unset CDPATH DISPLAY ||:\
>>>   %{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\
>>>   export RPM_BUILD_ROOT}\
>>>   %{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\
>>>   export CLASSPATH}\
>>>
>>> PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
>>>   export PKG_CONFIG_PATH\
>>>   CONFIG_SITE=${CONFIG_SITE:-NONE}\
>>>   export CONFIG_SITE\
>>>   \
>>>   %{verbose:set -x}\
>>>   umask 022\
>>>   cd \"%{u2p:%{_builddir}}\"\
>>>
>>>
>>> You should b able to expand (redefine anywhere else) this macro to set the 
>>> variables you need or call %set_build_flags.
>>>
>> I did another mass rebuild, this time setting the CC and CXX environment 
>> variables
>> in __build_pre as you suggested.  The numbers look a little better now:
>>
>> Packages Built:4271
>> Built with clang:  3355
>> Built with gcc:916
>>
>> cc or c++ was invoked by about 50 packages.
> 
> 
> I just wonder, are there builds done in any particular order? E.g. build
> Ruby prior any rubygem- package, build Python prior python- packages, etc.
> 

No, I'm just building them all with mock and not into a buildroot.  I know
this causes an issue with perl and python packages, because they inherit
their cflags from the cflags used to build the interpreter.

-Tom

> 
> Vít
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Vít Ondruch]

Dne 11. 01. 20 v 5:46 Tom Stellard napsal(a):
> On 01/08/2020 11:28 PM, Miro Hrončok wrote:
>> On 08. 01. 20 23:47, Tom Stellard wrote:
>>> I suspect that if I can find some way to set the CC and CXX environment
>>> variables for all builds, not just ones using autoconf, cmake or meson,
>>> that might help cut down on the number of packages that still use gcc.
>>> I'm just not quite sure how to implement this yet, but I'm looking into
>>> it.
>> /usr/lib/rpm/macros has:
>>
>> %___build_pre\
>>   RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
>>   RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
>>   RPM_OPT_FLAGS=\"%{optflags}\"\
>>   RPM_LD_FLAGS=\"%{?build_ldflags}\"\
>>   RPM_ARCH=\"%{_arch}\"\
>>   RPM_OS=\"%{_os}\"\
>>   RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
>>   export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
>> RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS\
>>   RPM_DOC_DIR=\"%{_docdir}\"\
>>   export RPM_DOC_DIR\
>>   RPM_PACKAGE_NAME=\"%{NAME}\"\
>>   RPM_PACKAGE_VERSION=\"%{VERSION}\"\
>>   RPM_PACKAGE_RELEASE=\"%{RELEASE}\"\
>>   export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE\
>>   LANG=C\
>>   export LANG\
>>   unset CDPATH DISPLAY ||:\
>>   %{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\
>>   export RPM_BUILD_ROOT}\
>>   %{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\
>>   export CLASSPATH}\
>>
>> PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
>>   export PKG_CONFIG_PATH\
>>   CONFIG_SITE=${CONFIG_SITE:-NONE}\
>>   export CONFIG_SITE\
>>   \
>>   %{verbose:set -x}\
>>   umask 022\
>>   cd \"%{u2p:%{_builddir}}\"\
>>
>>
>> You should b able to expand (redefine anywhere else) this macro to set the 
>> variables you need or call %set_build_flags.
>>
> I did another mass rebuild, this time setting the CC and CXX environment 
> variables
> in __build_pre as you suggested.  The numbers look a little better now:
>
> Packages Built:4271
> Built with clang:  3355
> Built with gcc:916
>
> cc or c++ was invoked by about 50 packages.


I just wonder, are there builds done in any particular order? E.g. build
Ruby prior any rubygem- package, build Python prior python- packages, etc.


Vít
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 01/08/2020 11:28 PM, Miro Hrončok wrote:
> On 08. 01. 20 23:47, Tom Stellard wrote:
>> I suspect that if I can find some way to set the CC and CXX environment
>> variables for all builds, not just ones using autoconf, cmake or meson,
>> that might help cut down on the number of packages that still use gcc.
>> I'm just not quite sure how to implement this yet, but I'm looking into
>> it.
> 
> /usr/lib/rpm/macros has:
> 
> %___build_pre\
>   RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
>   RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
>   RPM_OPT_FLAGS=\"%{optflags}\"\
>   RPM_LD_FLAGS=\"%{?build_ldflags}\"\
>   RPM_ARCH=\"%{_arch}\"\
>   RPM_OS=\"%{_os}\"\
>   RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
>   export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
> RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS\
>   RPM_DOC_DIR=\"%{_docdir}\"\
>   export RPM_DOC_DIR\
>   RPM_PACKAGE_NAME=\"%{NAME}\"\
>   RPM_PACKAGE_VERSION=\"%{VERSION}\"\
>   RPM_PACKAGE_RELEASE=\"%{RELEASE}\"\
>   export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE\
>   LANG=C\
>   export LANG\
>   unset CDPATH DISPLAY ||:\
>   %{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\
>   export RPM_BUILD_ROOT}\
>   %{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\
>   export CLASSPATH}\
> 
> PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
>   export PKG_CONFIG_PATH\
>   CONFIG_SITE=${CONFIG_SITE:-NONE}\
>   export CONFIG_SITE\
>   \
>   %{verbose:set -x}\
>   umask 022\
>   cd \"%{u2p:%{_builddir}}\"\
> 
> 
> You should b able to expand (redefine anywhere else) this macro to set the 
> variables you need or call %set_build_flags.
> 

I did another mass rebuild, this time setting the CC and CXX environment 
variables
in __build_pre as you suggested.  The numbers look a little better now:

Packages Built:4271
Built with clang:  3355
Built with gcc:916

cc or c++ was invoked by about 50 packages.

-Tom
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Nicolas Chauvet]

Le jeu. 9 janv. 2020 à 17:42, Tom Stellard  a écrit :
>
> On 01/08/2020 11:40 PM, Igor Gnatenko wrote:
> > So this just means that packages do not respect the environment. What about 
> > fixing them instead of trying to hack the environment?
> >
>
> Do you mean that packages should be updated to respect the __cc and __cxx 
> macros?

At least build systems must obey to CC and others environment
variables. So anything not compliant is an upstream bug (or an issue
in the RPM macro ?).
Theses are extremely high numbers, but unlikely to provide anything
meaningful until one can dive into the root cause, at least for for
few of them.
There are probably few error patterns that can be fixed.


-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 01/08/2020 11:40 PM, Igor Gnatenko wrote:
> So this just means that packages do not respect the environment. What about 
> fixing them instead of trying to hack the environment?
> 

Do you mean that packages should be updated to respect the __cc and __cxx 
macros?

-Tom

> On Wed, Jan 8, 2020, 23:53 Tom Stellard  > wrote:
> 
> On 12/23/2019 11:59 AM, Tom Stellard wrote:
> > On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote:
> >>
> >>
> >> On Sat, 21 Dec 2019 at 00:37, Neal Gompa    >> wrote:
> >> [..]
> >>
> >> I believe it's also used by the %cmake and %meson macros.
> >>
> >>
> >> Yep.
> >> Look on the output of the “rpm -E %cmake” and you will find that to 
> switch to other C and C++ compilers all what you need to do is redefine %__cc 
> and %__cxx macros,
> >
> > I'm not seeing this, at least with the current rawhide build, but I
> > patched cmake to enable this in the latest mass rebuild that I'm doing.
> > I'll post numbers on how effective using __cc and __cxx are once it's
> > complete.
> >
> 
> I completed a rebuild of all rawhide with the following modifications:
> 
> 1. Added this to %set_build_flags
> 
> CC="${CC:-%{__cc}}" ; export CC ; \
> CXX="${CXX:-%{__cxx}}"; export CXX ; \
> 
> 2. Added %set_build_flags to %cmake macro
> 
> 3. Remove -fstack-clash-protection and add -Qunused-arguments flags to 
> %optflags
> 
> 4. Set these macros:
> 
> config_opts['macros']['%__cc'] = "clang"
> config_opts['macros']['%__cxx'] = "clang++"
> config_opts['macros']['%__cpp'] = "clang-cpp"
> config_opts['macros']['%build_cflags'] = optflags
> config_opts['macros']['%build_cxxflags'] = optflags
> 
> 
> Here are the results:
> 
> Packages Built: 4228
> Built with clang: 2695
> Built with gcc: 1533
> 
> Based on grep'ing logs, around 320 of the packages built with gcc invoke
> gcc using cc or c++.  It's hard to know the exact number though, because
> I'm not sure if all packages echo their build steps and also my grep 
> expressions
> may not have caught everything.
> 
> I suspect that if I can find some way to set the CC and CXX environment
> variables for all builds, not just ones using autoconf, cmake or meson,
> that might help cut down on the number of packages that still use gcc.
> I'm just not quite sure how to implement this yet, but I'm looking into
> it.
> 
> -Tom
> 
> 
> > -Tom
> >
> >> The same is with %configure and %meson,
> >>
> >> In other words you can switch NOW from non-root account to other 
> compiler without execution update-alternatives from root.
> >>
> >> In other words this proposal is pointless.
> >>
> >> kloczek
> >> --
> >> --
> >> Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH*
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org 
> 
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> > Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org 
> 
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org 
> 
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Igor Gnatenko]

So this just means that packages do not respect the environment. What about
fixing them instead of trying to hack the environment?

On Wed, Jan 8, 2020, 23:53 Tom Stellard  wrote:

> On 12/23/2019 11:59 AM, Tom Stellard wrote:
> > On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote:
> >>
> >>
> >> On Sat, 21 Dec 2019 at 00:37, Neal Gompa  ngomp...@gmail.com>> wrote:
> >> [..]
> >>
> >> I believe it's also used by the %cmake and %meson macros.
> >>
> >>
> >> Yep.
> >> Look on the output of the “rpm -E %cmake” and you will find that to
> switch to other C and C++ compilers all what you need to do is redefine
> %__cc and %__cxx macros,
> >
> > I'm not seeing this, at least with the current rawhide build, but I
> > patched cmake to enable this in the latest mass rebuild that I'm doing.
> > I'll post numbers on how effective using __cc and __cxx are once it's
> > complete.
> >
>
> I completed a rebuild of all rawhide with the following modifications:
>
> 1. Added this to %set_build_flags
>
> CC="${CC:-%{__cc}}" ; export CC ; \
> CXX="${CXX:-%{__cxx}}"; export CXX ; \
>
> 2. Added %set_build_flags to %cmake macro
>
> 3. Remove -fstack-clash-protection and add -Qunused-arguments flags to
> %optflags
>
> 4. Set these macros:
>
> config_opts['macros']['%__cc'] = "clang"
> config_opts['macros']['%__cxx'] = "clang++"
> config_opts['macros']['%__cpp'] = "clang-cpp"
> config_opts['macros']['%build_cflags'] = optflags
> config_opts['macros']['%build_cxxflags'] = optflags
>
>
> Here are the results:
>
> Packages Built: 4228
> Built with clang: 2695
> Built with gcc: 1533
>
> Based on grep'ing logs, around 320 of the packages built with gcc invoke
> gcc using cc or c++.  It's hard to know the exact number though, because
> I'm not sure if all packages echo their build steps and also my grep
> expressions
> may not have caught everything.
>
> I suspect that if I can find some way to set the CC and CXX environment
> variables for all builds, not just ones using autoconf, cmake or meson,
> that might help cut down on the number of packages that still use gcc.
> I'm just not quite sure how to implement this yet, but I'm looking into
> it.
>
> -Tom
>
>
> > -Tom
> >
> >> The same is with %configure and %meson,
> >>
> >> In other words you can switch NOW from non-root account to other
> compiler without execution update-alternatives from root.
> >>
> >> In other words this proposal is pointless.
> >>
> >> kloczek
> >> --
> >> --
> >> Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH*
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> >
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Miro Hrončok]

On 08. 01. 20 23:47, Tom Stellard wrote:

I suspect that if I can find some way to set the CC and CXX environment
variables for all builds, not just ones using autoconf, cmake or meson,
that might help cut down on the number of packages that still use gcc.
I'm just not quite sure how to implement this yet, but I'm looking into
it.


/usr/lib/rpm/macros has:

%___build_pre   \
  RPM_SOURCE_DIR=\"%{u2p:%{_sourcedir}}\"\
  RPM_BUILD_DIR=\"%{u2p:%{_builddir}}\"\
  RPM_OPT_FLAGS=\"%{optflags}\"\
  RPM_LD_FLAGS=\"%{?build_ldflags}\"\
  RPM_ARCH=\"%{_arch}\"\
  RPM_OS=\"%{_os}\"\
  RPM_BUILD_NCPUS=\"%{_smp_build_ncpus}\"\
  export RPM_SOURCE_DIR RPM_BUILD_DIR RPM_OPT_FLAGS RPM_LD_FLAGS RPM_ARCH 
RPM_OS RPM_BUILD_NCPUS RPM_LD_FLAGS\

  RPM_DOC_DIR=\"%{_docdir}\"\
  export RPM_DOC_DIR\
  RPM_PACKAGE_NAME=\"%{NAME}\"\
  RPM_PACKAGE_VERSION=\"%{VERSION}\"\
  RPM_PACKAGE_RELEASE=\"%{RELEASE}\"\
  export RPM_PACKAGE_NAME RPM_PACKAGE_VERSION RPM_PACKAGE_RELEASE\
  LANG=C\
  export LANG\
  unset CDPATH DISPLAY ||:\
  %{?buildroot:RPM_BUILD_ROOT=\"%{u2p:%{buildroot}}\"\
  export RPM_BUILD_ROOT}\
  %{?_javaclasspath:CLASSPATH=\"%{_javaclasspath}\"\
  export CLASSPATH}\

PKG_CONFIG_PATH=\"${PKG_CONFIG_PATH}:%{_libdir}/pkgconfig:%{_datadir}/pkgconfig\"\
  export PKG_CONFIG_PATH\
  CONFIG_SITE=${CONFIG_SITE:-NONE}\
  export CONFIG_SITE\
  \
  %{verbose:set -x}\
  umask 022\
  cd \"%{u2p:%{_builddir}}\"\


You should b able to expand (redefine anywhere else) this macro to set the 
variables you need or call %set_build_flags.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/23/2019 11:59 AM, Tom Stellard wrote:
> On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote:
>>
>>
>> On Sat, 21 Dec 2019 at 00:37, Neal Gompa > > wrote:
>> [..]
>>
>> I believe it's also used by the %cmake and %meson macros.
>>
>>
>> Yep.
>> Look on the output of the “rpm -E %cmake” and you will find that to switch 
>> to other C and C++ compilers all what you need to do is redefine %__cc and 
>> %__cxx macros,
> 
> I'm not seeing this, at least with the current rawhide build, but I
> patched cmake to enable this in the latest mass rebuild that I'm doing.
> I'll post numbers on how effective using __cc and __cxx are once it's
> complete.
> 

I completed a rebuild of all rawhide with the following modifications:

1. Added this to %set_build_flags

CC="${CC:-%{__cc}}" ; export CC ; \
CXX="${CXX:-%{__cxx}}"; export CXX ; \

2. Added %set_build_flags to %cmake macro

3. Remove -fstack-clash-protection and add -Qunused-arguments flags to %optflags

4. Set these macros:

config_opts['macros']['%__cc'] = "clang"
config_opts['macros']['%__cxx'] = "clang++"
config_opts['macros']['%__cpp'] = "clang-cpp"
config_opts['macros']['%build_cflags'] = optflags
config_opts['macros']['%build_cxxflags'] = optflags


Here are the results:

Packages Built: 4228
Built with clang: 2695
Built with gcc: 1533

Based on grep'ing logs, around 320 of the packages built with gcc invoke
gcc using cc or c++.  It's hard to know the exact number though, because
I'm not sure if all packages echo their build steps and also my grep expressions
may not have caught everything.

I suspect that if I can find some way to set the CC and CXX environment
variables for all builds, not just ones using autoconf, cmake or meson,
that might help cut down on the number of packages that still use gcc.
I'm just not quite sure how to implement this yet, but I'm looking into
it.

-Tom


> -Tom
> 
>> The same is with %configure and %meson,
>>
>> In other words you can switch NOW from non-root account to other compiler 
>> without execution update-alternatives from root.
>>
>> In other words this proposal is pointless.
>>
>> kloczek
>> -- 
>> -- 
>> Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH*
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/21/2019 02:30 PM, Tomasz Kłoczko wrote:
> 
> 
> On Sat, 21 Dec 2019 at 00:37, Neal Gompa  > wrote:
> [..]
> 
> I believe it's also used by the %cmake and %meson macros.
> 
> 
> Yep.
> Look on the output of the “rpm -E %cmake” and you will find that to switch to 
> other C and C++ compilers all what you need to do is redefine %__cc and 
> %__cxx macros,

I'm not seeing this, at least with the current rawhide build, but I
patched cmake to enable this in the latest mass rebuild that I'm doing.
I'll post numbers on how effective using __cc and __cxx are once it's
complete.

-Tom

> The same is with %configure and %meson,
> 
> In other words you can switch NOW from non-root account to other compiler 
> without execution update-alternatives from root.
> 
> In other words this proposal is pointless.
> 
> kloczek
> -- 
> -- 
> Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tomasz Kłoczko]

On Sat, 21 Dec 2019 at 00:37, Neal Gompa  wrote:
[..]

> I believe it's also used by the %cmake and %meson macros.


Yep.
Look on the output of the “rpm -E %cmake” and you will find that to switch
to other C and C++ compilers all what you need to do is redefine %__cc and
%__cxx macros,
The same is with %configure and %meson,

In other words you can switch NOW from non-root account to other compiler
without execution update-alternatives from root.

In other words this proposal is pointless.

kloczek
-- 
-- 
Tomasz Kłoczko | Tel: 0774 1209067 | LinkedIn: *http://lnkd.in/FXPWxH
*
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Neal Gompa]

On Fri, Dec 20, 2019 at 5:25 PM Tom Stellard  wrote:
>
> On 12/20/2019 03:20 PM, Neal Gompa wrote:
> > On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard  wrote:
> >>
> >> On 12/20/2019 02:01 PM, Neal Gompa wrote:
> >>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard  wrote:
> 
>  On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> > Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
> >>
> >> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
> >>
> >> == Summary ==
> >> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> >> symlinks are managed by update-alternatives.
> >>
> >> == Owner ==
> >> * Name: [[User:tstellar| Tom Stellard]]
> >> * Email: 
> >>
> >> == Detailed Description ==
> >> The gcc package currently installs symlinks to /usr/bin/cc and
> >> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> >> respectively.  For this change, the gcc package will be modified so
> >> that update-alternatives creates and manages these symlinks.
> >>
> >> In addition to modifying the gcc package, the clang package will be
> >> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> >> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
> >> will have a lower priority than the gcc alternatives, so that by
> >> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> >> implementations.
> >>
> >> The clang package currently has a run-time dependency on gcc, so this
> >> ensures that gcc will always provide the default implementation,
> >> because it's impossible to install clang without gcc.
> >>
> >> The only way users will be able to change the /usr/bin/cc or
> >> /usr/bin/c++ implementations will be by explicitly using the
> >> update-alternatives tool.
> >>
> >> == Benefit to Fedora ==
> >> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> >> the default C/C++ compilers.  Being able to easily swap out these
> >> implementation will provide a lot of flexibility within Fedora for
> >> doing things like:
> >>
> >> * Setting up alternative buildroots for testing.
> >> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> >> packages to new compiler flags or to capture statistics about compiler
> >> usage.
> >> * Letting users experiment easily with alternate compilers.
> >> * Easily switch between system gcc and a development version of gcc.
> >>
> >> == Scope ==
> >> * Proposal owners: The proposal owner will implement the necessary
> >> changes in the gcc and clang packages.
> >>
> >> * Other developers: The gcc maintainers will be responsible for
> >> reviewing and approving changes to the gcc package.
> >>
> >> * Release engineering: (a check of an impact with Release Engineering 
> >> is needed)
> >> * Policies and guidelines: No policies or guidelines will need to be
> >> updated as a result of this change.
> >> * Trademark approval: N/A (not needed for this Change)
> >>
> >>
> >> == Upgrade/compatibility impact ==
> >> This change should not impact upgradeability.
> >>
> >> == How To Test ==
> >> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> >> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> >> installed.  There will also be a CI test added to the clang package to
> >> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> >> clang is installed.
> >>
> >> == User Experience ==
> >> This change will give users a much better way to experiment using
> >> other compilers for their own development.  They will be able to
> >> easily switch between different compilers without having to modify
> >> their projects build system or make non-standard changes to their
> >> Fedora system.
> >>
> >> == Dependencies ==
> >> This change has no other dependencies besides the changes to the gcc
> >> and clang packages.
> >>
> >> == Contingency Plan ==
> >> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
> >> will revert changes made to gcc and clang packages and rebuild.
> >> * Contingency deadline: If the changes are not complete by 2 weeks
> >> before the mass rebuild, then we will consider postponing to the next
> >> Fedora release and back out any changes that were made.
> >> * Blocks release? No
> >> * Blocks product? None
> >>
> >> == Documentation ==
> >> Release notes will be added for this change.
> >>
> >> == Release Notes ==
> >> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> >> update-alternatives.  If you would like to change these symlinks to
> >> point to another compiler, like clang, for example, you can use 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/20/2019 03:20 PM, Neal Gompa wrote:
> On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard  wrote:
>>
>> On 12/20/2019 02:01 PM, Neal Gompa wrote:
>>> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard  wrote:

 On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
>>
>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>>
>> == Summary ==
>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>> symlinks are managed by update-alternatives.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: 
>>
>> == Detailed Description ==
>> The gcc package currently installs symlinks to /usr/bin/cc and
>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>> respectively.  For this change, the gcc package will be modified so
>> that update-alternatives creates and manages these symlinks.
>>
>> In addition to modifying the gcc package, the clang package will be
>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
>> will have a lower priority than the gcc alternatives, so that by
>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>> implementations.
>>
>> The clang package currently has a run-time dependency on gcc, so this
>> ensures that gcc will always provide the default implementation,
>> because it's impossible to install clang without gcc.
>>
>> The only way users will be able to change the /usr/bin/cc or
>> /usr/bin/c++ implementations will be by explicitly using the
>> update-alternatives tool.
>>
>> == Benefit to Fedora ==
>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>> the default C/C++ compilers.  Being able to easily swap out these
>> implementation will provide a lot of flexibility within Fedora for
>> doing things like:
>>
>> * Setting up alternative buildroots for testing.
>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>> packages to new compiler flags or to capture statistics about compiler
>> usage.
>> * Letting users experiment easily with alternate compilers.
>> * Easily switch between system gcc and a development version of gcc.
>>
>> == Scope ==
>> * Proposal owners: The proposal owner will implement the necessary
>> changes in the gcc and clang packages.
>>
>> * Other developers: The gcc maintainers will be responsible for
>> reviewing and approving changes to the gcc package.
>>
>> * Release engineering: (a check of an impact with Release Engineering is 
>> needed)
>> * Policies and guidelines: No policies or guidelines will need to be
>> updated as a result of this change.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> This change should not impact upgradeability.
>>
>> == How To Test ==
>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>> installed.  There will also be a CI test added to the clang package to
>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>> clang is installed.
>>
>> == User Experience ==
>> This change will give users a much better way to experiment using
>> other compilers for their own development.  They will be able to
>> easily switch between different compilers without having to modify
>> their projects build system or make non-standard changes to their
>> Fedora system.
>>
>> == Dependencies ==
>> This change has no other dependencies besides the changes to the gcc
>> and clang packages.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
>> will revert changes made to gcc and clang packages and rebuild.
>> * Contingency deadline: If the changes are not complete by 2 weeks
>> before the mass rebuild, then we will consider postponing to the next
>> Fedora release and back out any changes that were made.
>> * Blocks release? No
>> * Blocks product? None
>>
>> == Documentation ==
>> Release notes will be added for this change.
>>
>> == Release Notes ==
>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>> update-alternatives.  If you would like to change these symlinks to
>> point to another compiler, like clang, for example, you can use these
>> commands:
>>
>> `update-alternatives --set cc /usr/bin/clang`
>>
>> `update-alternatives --set c++ /usr/bin/clang++`
>
> Does this process even works in RPM context ? given rpm -E %{__cc}
> outputs gcc, I don't think 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Neal Gompa]

On Fri, Dec 20, 2019 at 5:19 PM Tom Stellard  wrote:
>
> On 12/20/2019 02:01 PM, Neal Gompa wrote:
> > On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard  wrote:
> >>
> >> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> >>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
> 
>  https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
> 
>  == Summary ==
>  Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>  symlinks are managed by update-alternatives.
> 
>  == Owner ==
>  * Name: [[User:tstellar| Tom Stellard]]
>  * Email: 
> 
>  == Detailed Description ==
>  The gcc package currently installs symlinks to /usr/bin/cc and
>  /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>  respectively.  For this change, the gcc package will be modified so
>  that update-alternatives creates and manages these symlinks.
> 
>  In addition to modifying the gcc package, the clang package will be
>  modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>  alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
>  will have a lower priority than the gcc alternatives, so that by
>  default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>  implementations.
> 
>  The clang package currently has a run-time dependency on gcc, so this
>  ensures that gcc will always provide the default implementation,
>  because it's impossible to install clang without gcc.
> 
>  The only way users will be able to change the /usr/bin/cc or
>  /usr/bin/c++ implementations will be by explicitly using the
>  update-alternatives tool.
> 
>  == Benefit to Fedora ==
>  Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>  the default C/C++ compilers.  Being able to easily swap out these
>  implementation will provide a lot of flexibility within Fedora for
>  doing things like:
> 
>  * Setting up alternative buildroots for testing.
>  * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>  packages to new compiler flags or to capture statistics about compiler
>  usage.
>  * Letting users experiment easily with alternate compilers.
>  * Easily switch between system gcc and a development version of gcc.
> 
>  == Scope ==
>  * Proposal owners: The proposal owner will implement the necessary
>  changes in the gcc and clang packages.
> 
>  * Other developers: The gcc maintainers will be responsible for
>  reviewing and approving changes to the gcc package.
> 
>  * Release engineering: (a check of an impact with Release Engineering is 
>  needed)
>  * Policies and guidelines: No policies or guidelines will need to be
>  updated as a result of this change.
>  * Trademark approval: N/A (not needed for this Change)
> 
> 
>  == Upgrade/compatibility impact ==
>  This change should not impact upgradeability.
> 
>  == How To Test ==
>  CI tests will be added to the gcc package to ensure that /usr/bin/cc
>  and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>  installed.  There will also be a CI test added to the clang package to
>  ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>  clang is installed.
> 
>  == User Experience ==
>  This change will give users a much better way to experiment using
>  other compilers for their own development.  They will be able to
>  easily switch between different compilers without having to modify
>  their projects build system or make non-standard changes to their
>  Fedora system.
> 
>  == Dependencies ==
>  This change has no other dependencies besides the changes to the gcc
>  and clang packages.
> 
>  == Contingency Plan ==
>  * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
>  will revert changes made to gcc and clang packages and rebuild.
>  * Contingency deadline: If the changes are not complete by 2 weeks
>  before the mass rebuild, then we will consider postponing to the next
>  Fedora release and back out any changes that were made.
>  * Blocks release? No
>  * Blocks product? None
> 
>  == Documentation ==
>  Release notes will be added for this change.
> 
>  == Release Notes ==
>  The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>  update-alternatives.  If you would like to change these symlinks to
>  point to another compiler, like clang, for example, you can use these
>  commands:
> 
>  `update-alternatives --set cc /usr/bin/clang`
> 
>  `update-alternatives --set c++ /usr/bin/clang++`
> >>>
> >>> Does this process even works in RPM context ? given rpm -E %{__cc}
> >>> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> >>> for 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/20/2019 02:01 PM, Neal Gompa wrote:
> On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard  wrote:
>>
>> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
>>> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :

 https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc

 == Summary ==
 Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
 symlinks are managed by update-alternatives.

 == Owner ==
 * Name: [[User:tstellar| Tom Stellard]]
 * Email: 

 == Detailed Description ==
 The gcc package currently installs symlinks to /usr/bin/cc and
 /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
 respectively.  For this change, the gcc package will be modified so
 that update-alternatives creates and manages these symlinks.

 In addition to modifying the gcc package, the clang package will be
 modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
 alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
 will have a lower priority than the gcc alternatives, so that by
 default, gcc will provide the /usr/bin/cc and /usr/bin/c++
 implementations.

 The clang package currently has a run-time dependency on gcc, so this
 ensures that gcc will always provide the default implementation,
 because it's impossible to install clang without gcc.

 The only way users will be able to change the /usr/bin/cc or
 /usr/bin/c++ implementations will be by explicitly using the
 update-alternatives tool.

 == Benefit to Fedora ==
 Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
 the default C/C++ compilers.  Being able to easily swap out these
 implementation will provide a lot of flexibility within Fedora for
 doing things like:

 * Setting up alternative buildroots for testing.
 * Installing a gcc wrapper script to /usr/bin/cc to help migrate
 packages to new compiler flags or to capture statistics about compiler
 usage.
 * Letting users experiment easily with alternate compilers.
 * Easily switch between system gcc and a development version of gcc.

 == Scope ==
 * Proposal owners: The proposal owner will implement the necessary
 changes in the gcc and clang packages.

 * Other developers: The gcc maintainers will be responsible for
 reviewing and approving changes to the gcc package.

 * Release engineering: (a check of an impact with Release Engineering is 
 needed)
 * Policies and guidelines: No policies or guidelines will need to be
 updated as a result of this change.
 * Trademark approval: N/A (not needed for this Change)


 == Upgrade/compatibility impact ==
 This change should not impact upgradeability.

 == How To Test ==
 CI tests will be added to the gcc package to ensure that /usr/bin/cc
 and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
 installed.  There will also be a CI test added to the clang package to
 ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
 clang is installed.

 == User Experience ==
 This change will give users a much better way to experiment using
 other compilers for their own development.  They will be able to
 easily switch between different compilers without having to modify
 their projects build system or make non-standard changes to their
 Fedora system.

 == Dependencies ==
 This change has no other dependencies besides the changes to the gcc
 and clang packages.

 == Contingency Plan ==
 * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
 will revert changes made to gcc and clang packages and rebuild.
 * Contingency deadline: If the changes are not complete by 2 weeks
 before the mass rebuild, then we will consider postponing to the next
 Fedora release and back out any changes that were made.
 * Blocks release? No
 * Blocks product? None

 == Documentation ==
 Release notes will be added for this change.

 == Release Notes ==
 The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
 update-alternatives.  If you would like to change these symlinks to
 point to another compiler, like clang, for example, you can use these
 commands:

 `update-alternatives --set cc /usr/bin/clang`

 `update-alternatives --set c++ /usr/bin/clang++`
>>>
>>> Does this process even works in RPM context ? given rpm -E %{__cc}
>>> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
>>> for __cxx, __cpp)
>>
>> /usr/bin/cc is the default compiler for cmake projects.
>>
>>> If that's only supposed to work in a local compilation context (not
>>> with RPM), what is the benefit from using alternatives rather than
>>> export CC=clang ?
>>
>> I'm actually not sure how 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Neal Gompa]

On Fri, Dec 20, 2019 at 3:24 PM Tom Stellard  wrote:
>
> On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> > Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
> >>
> >> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
> >>
> >> == Summary ==
> >> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> >> symlinks are managed by update-alternatives.
> >>
> >> == Owner ==
> >> * Name: [[User:tstellar| Tom Stellard]]
> >> * Email: 
> >>
> >> == Detailed Description ==
> >> The gcc package currently installs symlinks to /usr/bin/cc and
> >> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> >> respectively.  For this change, the gcc package will be modified so
> >> that update-alternatives creates and manages these symlinks.
> >>
> >> In addition to modifying the gcc package, the clang package will be
> >> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> >> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
> >> will have a lower priority than the gcc alternatives, so that by
> >> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> >> implementations.
> >>
> >> The clang package currently has a run-time dependency on gcc, so this
> >> ensures that gcc will always provide the default implementation,
> >> because it's impossible to install clang without gcc.
> >>
> >> The only way users will be able to change the /usr/bin/cc or
> >> /usr/bin/c++ implementations will be by explicitly using the
> >> update-alternatives tool.
> >>
> >> == Benefit to Fedora ==
> >> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> >> the default C/C++ compilers.  Being able to easily swap out these
> >> implementation will provide a lot of flexibility within Fedora for
> >> doing things like:
> >>
> >> * Setting up alternative buildroots for testing.
> >> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> >> packages to new compiler flags or to capture statistics about compiler
> >> usage.
> >> * Letting users experiment easily with alternate compilers.
> >> * Easily switch between system gcc and a development version of gcc.
> >>
> >> == Scope ==
> >> * Proposal owners: The proposal owner will implement the necessary
> >> changes in the gcc and clang packages.
> >>
> >> * Other developers: The gcc maintainers will be responsible for
> >> reviewing and approving changes to the gcc package.
> >>
> >> * Release engineering: (a check of an impact with Release Engineering is 
> >> needed)
> >> * Policies and guidelines: No policies or guidelines will need to be
> >> updated as a result of this change.
> >> * Trademark approval: N/A (not needed for this Change)
> >>
> >>
> >> == Upgrade/compatibility impact ==
> >> This change should not impact upgradeability.
> >>
> >> == How To Test ==
> >> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> >> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> >> installed.  There will also be a CI test added to the clang package to
> >> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> >> clang is installed.
> >>
> >> == User Experience ==
> >> This change will give users a much better way to experiment using
> >> other compilers for their own development.  They will be able to
> >> easily switch between different compilers without having to modify
> >> their projects build system or make non-standard changes to their
> >> Fedora system.
> >>
> >> == Dependencies ==
> >> This change has no other dependencies besides the changes to the gcc
> >> and clang packages.
> >>
> >> == Contingency Plan ==
> >> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
> >> will revert changes made to gcc and clang packages and rebuild.
> >> * Contingency deadline: If the changes are not complete by 2 weeks
> >> before the mass rebuild, then we will consider postponing to the next
> >> Fedora release and back out any changes that were made.
> >> * Blocks release? No
> >> * Blocks product? None
> >>
> >> == Documentation ==
> >> Release notes will be added for this change.
> >>
> >> == Release Notes ==
> >> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> >> update-alternatives.  If you would like to change these symlinks to
> >> point to another compiler, like clang, for example, you can use these
> >> commands:
> >>
> >> `update-alternatives --set cc /usr/bin/clang`
> >>
> >> `update-alternatives --set c++ /usr/bin/clang++`
> >
> > Does this process even works in RPM context ? given rpm -E %{__cc}
> > outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> > for __cxx, __cpp)
>
> /usr/bin/cc is the default compiler for cmake projects.
>
> > If that's only supposed to work in a local compilation context (not
> > with RPM), what is the benefit from using alternatives rather than
> > export CC=clang ?
>
> I'm actually not sure how much better alternatives is that using only 
> 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/20/2019 05:27 AM, Zbigniew Jędrzejewski-Szmek wrote:
> On Thu, Dec 19, 2019 at 03:47:13PM -0600, Neal Gompa wrote:
>>> == Release Notes ==
>>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>>> update-alternatives.  If you would like to change these symlinks to
>>> point to another compiler, like clang, for example, you can use these
>>> commands:
>>>
>>> `update-alternatives --set cc /usr/bin/clang`
>>>
>>> `update-alternatives --set c++ /usr/bin/clang++`
>>>
>>
>> I don't know if I want *more* alternatives usage in Fedora. I like the
>> fact that a basic buildroot is generally supposed to work without
>> scriptlets... On the other hand, I think we're already using
>> alternatives for ld...
>>
>> Aside from making it possible to swap the system compiler with
>> alternatives, what benefit do we get? Are there other, less script-y
>> approaches that we could use?
> 
> I'm not sure that the benefits are really that big. For most cases, instead
> of setting alternatives, the obvious solution would be to set $CC. Can you
> expand a bit on why alternatives, which is effectively a global setting,
> is preferred to a local override?
> 

This is a good point, and something I don't have numbers for yet.  As
mentioned in my other response, I've only done rebuilds with CC=/usr/bin/cc
*and* the alternatives changes together.  These changes together get around
~70% of the packages building with clang.

-Tom 


> Zbyszek
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/20/2019 03:33 AM, Nicolas Chauvet wrote:
> Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
>>
>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>>
>> == Summary ==
>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>> symlinks are managed by update-alternatives.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: 
>>
>> == Detailed Description ==
>> The gcc package currently installs symlinks to /usr/bin/cc and
>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>> respectively.  For this change, the gcc package will be modified so
>> that update-alternatives creates and manages these symlinks.
>>
>> In addition to modifying the gcc package, the clang package will be
>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
>> will have a lower priority than the gcc alternatives, so that by
>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>> implementations.
>>
>> The clang package currently has a run-time dependency on gcc, so this
>> ensures that gcc will always provide the default implementation,
>> because it's impossible to install clang without gcc.
>>
>> The only way users will be able to change the /usr/bin/cc or
>> /usr/bin/c++ implementations will be by explicitly using the
>> update-alternatives tool.
>>
>> == Benefit to Fedora ==
>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>> the default C/C++ compilers.  Being able to easily swap out these
>> implementation will provide a lot of flexibility within Fedora for
>> doing things like:
>>
>> * Setting up alternative buildroots for testing.
>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>> packages to new compiler flags or to capture statistics about compiler
>> usage.
>> * Letting users experiment easily with alternate compilers.
>> * Easily switch between system gcc and a development version of gcc.
>>
>> == Scope ==
>> * Proposal owners: The proposal owner will implement the necessary
>> changes in the gcc and clang packages.
>>
>> * Other developers: The gcc maintainers will be responsible for
>> reviewing and approving changes to the gcc package.
>>
>> * Release engineering: (a check of an impact with Release Engineering is 
>> needed)
>> * Policies and guidelines: No policies or guidelines will need to be
>> updated as a result of this change.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> This change should not impact upgradeability.
>>
>> == How To Test ==
>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>> installed.  There will also be a CI test added to the clang package to
>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>> clang is installed.
>>
>> == User Experience ==
>> This change will give users a much better way to experiment using
>> other compilers for their own development.  They will be able to
>> easily switch between different compilers without having to modify
>> their projects build system or make non-standard changes to their
>> Fedora system.
>>
>> == Dependencies ==
>> This change has no other dependencies besides the changes to the gcc
>> and clang packages.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
>> will revert changes made to gcc and clang packages and rebuild.
>> * Contingency deadline: If the changes are not complete by 2 weeks
>> before the mass rebuild, then we will consider postponing to the next
>> Fedora release and back out any changes that were made.
>> * Blocks release? No
>> * Blocks product? None
>>
>> == Documentation ==
>> Release notes will be added for this change.
>>
>> == Release Notes ==
>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>> update-alternatives.  If you would like to change these symlinks to
>> point to another compiler, like clang, for example, you can use these
>> commands:
>>
>> `update-alternatives --set cc /usr/bin/clang`
>>
>> `update-alternatives --set c++ /usr/bin/clang++`
> 
> Does this process even works in RPM context ? given rpm -E %{__cc}
> outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
> for __cxx, __cpp)

/usr/bin/cc is the default compiler for cmake projects.

> If that's only supposed to work in a local compilation context (not
> with RPM), what is the benefit from using alternatives rather than
> export CC=clang ?

I'm actually not sure how much better alternatives is that using only CC=clang.
I haven't done a full rebuild with only CC=clang and without
the proposed /usr/bin/cc alternative pointing to clang to see what the
numbers look like.

What I have done is build all the packages that depend on gcc with /usr/bin/cc
pointing to clang and also CC=/usr/bin/cc (and 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Tom Stellard]

On 12/19/2019 01:47 PM, Neal Gompa wrote:
> On Thu, Dec 19, 2019 at 3:44 PM Ben Cotton  wrote:
>>
>> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>>
>> == Summary ==
>> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
>> symlinks are managed by update-alternatives.
>>
>> == Owner ==
>> * Name: [[User:tstellar| Tom Stellard]]
>> * Email: 
>>
>> == Detailed Description ==
>> The gcc package currently installs symlinks to /usr/bin/cc and
>> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
>> respectively.  For this change, the gcc package will be modified so
>> that update-alternatives creates and manages these symlinks.
>>
>> In addition to modifying the gcc package, the clang package will be
>> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
>> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
>> will have a lower priority than the gcc alternatives, so that by
>> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
>> implementations.
>>
>> The clang package currently has a run-time dependency on gcc, so this
>> ensures that gcc will always provide the default implementation,
>> because it's impossible to install clang without gcc.
>>
>> The only way users will be able to change the /usr/bin/cc or
>> /usr/bin/c++ implementations will be by explicitly using the
>> update-alternatives tool.
>>
>> == Benefit to Fedora ==
>> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
>> the default C/C++ compilers.  Being able to easily swap out these
>> implementation will provide a lot of flexibility within Fedora for
>> doing things like:
>>
>> * Setting up alternative buildroots for testing.
>> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
>> packages to new compiler flags or to capture statistics about compiler
>> usage.
>> * Letting users experiment easily with alternate compilers.
>> * Easily switch between system gcc and a development version of gcc.
>>
>> == Scope ==
>> * Proposal owners: The proposal owner will implement the necessary
>> changes in the gcc and clang packages.
>>
>> * Other developers: The gcc maintainers will be responsible for
>> reviewing and approving changes to the gcc package.
>>
>> * Release engineering: (a check of an impact with Release Engineering is 
>> needed)
>> * Policies and guidelines: No policies or guidelines will need to be
>> updated as a result of this change.
>> * Trademark approval: N/A (not needed for this Change)
>>
>>
>> == Upgrade/compatibility impact ==
>> This change should not impact upgradeability.
>>
>> == How To Test ==
>> CI tests will be added to the gcc package to ensure that /usr/bin/cc
>> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
>> installed.  There will also be a CI test added to the clang package to
>> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
>> clang is installed.
>>
>> == User Experience ==
>> This change will give users a much better way to experiment using
>> other compilers for their own development.  They will be able to
>> easily switch between different compilers without having to modify
>> their projects build system or make non-standard changes to their
>> Fedora system.
>>
>> == Dependencies ==
>> This change has no other dependencies besides the changes to the gcc
>> and clang packages.
>>
>> == Contingency Plan ==
>> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
>> will revert changes made to gcc and clang packages and rebuild.
>> * Contingency deadline: If the changes are not complete by 2 weeks
>> before the mass rebuild, then we will consider postponing to the next
>> Fedora release and back out any changes that were made.
>> * Blocks release? No
>> * Blocks product? None
>>
>> == Documentation ==
>> Release notes will be added for this change.
>>
>> == Release Notes ==
>> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
>> update-alternatives.  If you would like to change these symlinks to
>> point to another compiler, like clang, for example, you can use these
>> commands:
>>
>> `update-alternatives --set cc /usr/bin/clang`
>>
>> `update-alternatives --set c++ /usr/bin/clang++`
>>
> 
> I don't know if I want *more* alternatives usage in Fedora. I like the
> fact that a basic buildroot is generally supposed to work without
> scriptlets... On the other hand, I think we're already using
> alternatives for ld...
> 
> Aside from making it possible to swap the system compiler with
> alternatives, what benefit do we get? Are there other, less script-y
> approaches that we could use?
> 
> 

The only benefit here is being able to swap out the system compiler.

For a typical user, I'm not sure there is a good alternative to this
for changing the default compiler.  However, there are other options
we have in the Fedora buildroots, to switch the default compiler, like
using the __cc and __cxx macros and making sure the 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Zbigniew Jędrzejewski-Szmek]

On Thu, Dec 19, 2019 at 03:47:13PM -0600, Neal Gompa wrote:
> > == Release Notes ==
> > The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> > update-alternatives.  If you would like to change these symlinks to
> > point to another compiler, like clang, for example, you can use these
> > commands:
> >
> > `update-alternatives --set cc /usr/bin/clang`
> >
> > `update-alternatives --set c++ /usr/bin/clang++`
> >
> 
> I don't know if I want *more* alternatives usage in Fedora. I like the
> fact that a basic buildroot is generally supposed to work without
> scriptlets... On the other hand, I think we're already using
> alternatives for ld...
> 
> Aside from making it possible to swap the system compiler with
> alternatives, what benefit do we get? Are there other, less script-y
> approaches that we could use?

I'm not sure that the benefits are really that big. For most cases, instead
of setting alternatives, the obvious solution would be to set $CC. Can you
expand a bit on why alternatives, which is effectively a global setting,
is preferred to a local override?

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Nicolas Chauvet]

Le jeu. 19 déc. 2019 à 22:44, Ben Cotton  a écrit :
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively.  For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers.  Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is 
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed.  There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development.  They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives.  If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`

Does this process even works in RPM context ? given rpm -E %{__cc}
outputs gcc, I don't think /usr/bin/cc is ever used anywhere. (same
for __cxx, __cpp)
If that's only supposed to work in a local compilation context (not
with RPM), what is the benefit from using alternatives rather than
export CC=clang ?
What about ccache ? (does it need to also be registered with alternatives) ?

As I imagine, setting clang for a given package with such alternatives
would requires to add a BR of some clang-default that will call
alternatives in %post.
At first sight, I would dramatically prefer to have a RPM macro that
would set __cc, __cpp,__cxx and the relevant cflags ldflgas in %prep.
(and eventually another macro that would set then back to default).

-- 
-

Nicolas (kwizart)
___
devel mailing list -- devel@lists.fedoraproject.org
To 

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Miro Hrončok]

On 19. 12. 19 22:47, Neal Gompa wrote:

I don't know if I want *more* alternatives usage in Fedora. I like the
fact that a basic buildroot is generally supposed to work without
scriptlets... On the other hand, I think we're already using
alternatives for ld...

Aside from making it possible to swap the system compiler with
alternatives, what benefit do we get? Are there other, less script-y
approaches that we could use?


We could have a cc-is-gcc and cc-is-clang conflicting packages with /ur/bin/cc 
and:


 - require /usr/bin/cc from gcc and from clang
 - suggest cc-is-gcc from gcc
 - suggest cc-is-clang from clang

That gets rid of the scriplets, but creates a nontrivial resolving chaos. Also 
when installing gcc and clang at the same time, we would not be able to 
trivially give cc-is-gcc higher priority unless we maybe suggest it from 
fedora-release, but that's... meh.


We could mix in some recommends, but the current behavior would probably try to 
install it on every upgrade, so not sure if that works.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Vitaly Zaitsev via devel]

On 19.12.2019 22:42, Ben Cotton wrote:
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.

It seems to me that it has already been implemented in old Fedora
releases as well as alternatives for text editors. Later it was decided
to drop them.

-- 
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Robin Lee]

On Fri, Dec 20, 2019 at 5:44 AM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively.  For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers.  Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is 
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed.  There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development.  They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives.  If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Alternatives for 'cpp' are needed, too. Clang has 'clang-cpp'.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 

Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc

== Summary ==
Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
symlinks are managed by update-alternatives.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 

== Detailed Description ==
The gcc package currently installs symlinks to /usr/bin/cc and
/usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
respectively.  For this change, the gcc package will be modified so
that update-alternatives creates and manages these symlinks.

In addition to modifying the gcc package, the clang package will be
modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
will have a lower priority than the gcc alternatives, so that by
default, gcc will provide the /usr/bin/cc and /usr/bin/c++
implementations.

The clang package currently has a run-time dependency on gcc, so this
ensures that gcc will always provide the default implementation,
because it's impossible to install clang without gcc.

The only way users will be able to change the /usr/bin/cc or
/usr/bin/c++ implementations will be by explicitly using the
update-alternatives tool.

== Benefit to Fedora ==
Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
the default C/C++ compilers.  Being able to easily swap out these
implementation will provide a lot of flexibility within Fedora for
doing things like:

* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate
packages to new compiler flags or to capture statistics about compiler
usage.
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.

== Scope ==
* Proposal owners: The proposal owner will implement the necessary
changes in the gcc and clang packages.

* Other developers: The gcc maintainers will be responsible for
reviewing and approving changes to the gcc package.

* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
CI tests will be added to the gcc package to ensure that /usr/bin/cc
and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
installed.  There will also be a CI test added to the clang package to
ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
clang is installed.

== User Experience ==
This change will give users a much better way to experiment using
other compilers for their own development.  They will be able to
easily switch between different compilers without having to modify
their projects build system or make non-standard changes to their
Fedora system.

== Dependencies ==
This change has no other dependencies besides the changes to the gcc
and clang packages.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
will revert changes made to gcc and clang packages and rebuild.
* Contingency deadline: If the changes are not complete by 2 weeks
before the mass rebuild, then we will consider postponing to the next
Fedora release and back out any changes that were made.
* Blocks release? No
* Blocks product? None

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
update-alternatives.  If you would like to change these symlinks to
point to another compiler, like clang, for example, you can use these
commands:

`update-alternatives --set cc /usr/bin/clang`

`update-alternatives --set c++ /usr/bin/clang++`

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Neal Gompa]

On Thu, Dec 19, 2019 at 3:44 PM Ben Cotton  wrote:
>
> https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc
>
> == Summary ==
> Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
> symlinks are managed by update-alternatives.
>
> == Owner ==
> * Name: [[User:tstellar| Tom Stellard]]
> * Email: 
>
> == Detailed Description ==
> The gcc package currently installs symlinks to /usr/bin/cc and
> /usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
> respectively.  For this change, the gcc package will be modified so
> that update-alternatives creates and manages these symlinks.
>
> In addition to modifying the gcc package, the clang package will be
> modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
> alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
> will have a lower priority than the gcc alternatives, so that by
> default, gcc will provide the /usr/bin/cc and /usr/bin/c++
> implementations.
>
> The clang package currently has a run-time dependency on gcc, so this
> ensures that gcc will always provide the default implementation,
> because it's impossible to install clang without gcc.
>
> The only way users will be able to change the /usr/bin/cc or
> /usr/bin/c++ implementations will be by explicitly using the
> update-alternatives tool.
>
> == Benefit to Fedora ==
> Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
> the default C/C++ compilers.  Being able to easily swap out these
> implementation will provide a lot of flexibility within Fedora for
> doing things like:
>
> * Setting up alternative buildroots for testing.
> * Installing a gcc wrapper script to /usr/bin/cc to help migrate
> packages to new compiler flags or to capture statistics about compiler
> usage.
> * Letting users experiment easily with alternate compilers.
> * Easily switch between system gcc and a development version of gcc.
>
> == Scope ==
> * Proposal owners: The proposal owner will implement the necessary
> changes in the gcc and clang packages.
>
> * Other developers: The gcc maintainers will be responsible for
> reviewing and approving changes to the gcc package.
>
> * Release engineering: (a check of an impact with Release Engineering is 
> needed)
> * Policies and guidelines: No policies or guidelines will need to be
> updated as a result of this change.
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> This change should not impact upgradeability.
>
> == How To Test ==
> CI tests will be added to the gcc package to ensure that /usr/bin/cc
> and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
> installed.  There will also be a CI test added to the clang package to
> ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
> clang is installed.
>
> == User Experience ==
> This change will give users a much better way to experiment using
> other compilers for their own development.  They will be able to
> easily switch between different compilers without having to modify
> their projects build system or make non-standard changes to their
> Fedora system.
>
> == Dependencies ==
> This change has no other dependencies besides the changes to the gcc
> and clang packages.
>
> == Contingency Plan ==
> * Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
> will revert changes made to gcc and clang packages and rebuild.
> * Contingency deadline: If the changes are not complete by 2 weeks
> before the mass rebuild, then we will consider postponing to the next
> Fedora release and back out any changes that were made.
> * Blocks release? No
> * Blocks product? None
>
> == Documentation ==
> Release notes will be added for this change.
>
> == Release Notes ==
> The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
> update-alternatives.  If you would like to change these symlinks to
> point to another compiler, like clang, for example, you can use these
> commands:
>
> `update-alternatives --set cc /usr/bin/clang`
>
> `update-alternatives --set c++ /usr/bin/clang++`
>

I don't know if I want *more* alternatives usage in Fedora. I like the
fact that a basic buildroot is generally supposed to work without
scriptlets... On the other hand, I think we're already using
alternatives for ld...

Aside from making it possible to swap the system compiler with
alternatives, what benefit do we get? Are there other, less script-y
approaches that we could use?


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Fedora 32 System-Wide Change proposal: Use update-alternatives for /usr/bin/cc and /usr/bin/c++

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/Use-Update-Alternatives-For-usr-bin-cc

== Summary ==
Modify the gcc package so that the /usr/bin/cc and /usr/bin/c++
symlinks are managed by update-alternatives.

== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: 

== Detailed Description ==
The gcc package currently installs symlinks to /usr/bin/cc and
/usr/bin/c++ which point to /usr/bin/gcc and /usr/bin/g++
respectively.  For this change, the gcc package will be modified so
that update-alternatives creates and manages these symlinks.

In addition to modifying the gcc package, the clang package will be
modified so that /usr/bin/clang and /usr/bin/clang++ can be used as
alternatives for /usr/bin/cc and /usr/bin/c++.  The clang alternatives
will have a lower priority than the gcc alternatives, so that by
default, gcc will provide the /usr/bin/cc and /usr/bin/c++
implementations.

The clang package currently has a run-time dependency on gcc, so this
ensures that gcc will always provide the default implementation,
because it's impossible to install clang without gcc.

The only way users will be able to change the /usr/bin/cc or
/usr/bin/c++ implementations will be by explicitly using the
update-alternatives tool.

== Benefit to Fedora ==
Many build systems default to using /usr/bin/cc and /usr/bin/c++ as
the default C/C++ compilers.  Being able to easily swap out these
implementation will provide a lot of flexibility within Fedora for
doing things like:

* Setting up alternative buildroots for testing.
* Installing a gcc wrapper script to /usr/bin/cc to help migrate
packages to new compiler flags or to capture statistics about compiler
usage.
* Letting users experiment easily with alternate compilers.
* Easily switch between system gcc and a development version of gcc.

== Scope ==
* Proposal owners: The proposal owner will implement the necessary
changes in the gcc and clang packages.

* Other developers: The gcc maintainers will be responsible for
reviewing and approving changes to the gcc package.

* Release engineering: (a check of an impact with Release Engineering is needed)
* Policies and guidelines: No policies or guidelines will need to be
updated as a result of this change.
* Trademark approval: N/A (not needed for this Change)


== Upgrade/compatibility impact ==
This change should not impact upgradeability.

== How To Test ==
CI tests will be added to the gcc package to ensure that /usr/bin/cc
and /usr/bin/c++ still point to /usr/bin/gcc and /usr/bin/g++ when
installed.  There will also be a CI test added to the clang package to
ensure that /usr/bin/gcc and /usr/bin/g++ remain the default when
clang is installed.

== User Experience ==
This change will give users a much better way to experiment using
other compilers for their own development.  They will be able to
easily switch between different compilers without having to modify
their projects build system or make non-standard changes to their
Fedora system.

== Dependencies ==
This change has no other dependencies besides the changes to the gcc
and clang packages.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) Proposal Owner
will revert changes made to gcc and clang packages and rebuild.
* Contingency deadline: If the changes are not complete by 2 weeks
before the mass rebuild, then we will consider postponing to the next
Fedora release and back out any changes that were made.
* Blocks release? No
* Blocks product? None

== Documentation ==
Release notes will be added for this change.

== Release Notes ==
The user /usr/bin/cc and /usr/bin/c++ symlinks are now managed by
update-alternatives.  If you would like to change these symlinks to
point to another compiler, like clang, for example, you can use these
commands:

`update-alternatives --set cc /usr/bin/clang`

`update-alternatives --set c++ /usr/bin/clang++`

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org