On 18 February 2018 at 17:09, Igor Gnatenko
<ignatenkobrain@xxxxxxxxxxxxxxxxx> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Over this weekend I've performed scratch-mass-rebuild without having gcc and
> gcc-c++ in buildroot of all Fedora packages, many of which failed due to random
> reasons and I grepped all logs for some common errors found by analyzing
> hundreds of build logs.
Yesterday I've replayed on your proposal but I've not realized that my
reply was held by the moderator.
You started introducing changes only after less than 24h after
publishing proposal.
It does not make any sense sending any proposals if you will be not
waiting for feedback at least few days :-/
Here is the copy of my yesterday reply:
As definitely proposed change will create the whole wave of small
changes adding at least one new BuildRequires I just started thinking
about going slightly deeper (but only a bit deeper ;) ).
When gcc or other compilers are no longer part of the core build env
suit/env as you mention it is necessary to add it straight in
BuildRequires for example gcc.
That is OK.
Q: does it really needs to be gcc? What about clang?
A: theoretically it does not need to be gcc .. especially as macros
like %cmake, %configure are injecting over CC, CXX and other variables
exact commands.
As long as none of the macros like %cmake or %cobfigure has straight
dependency and are not forcing to use gcc (those macros are using
other macros like %{__cc}) already it possible to test build package
written in C using C++ compiler to for example expose some set of
compile warnings generated by C++ compiler or .. use clang.
Build the whole package with using some C code security scanners? No
problem. It is possible to do this without touching spec file.
OK, so .. at the moment macros like:
%__cc gcc
%__cpp gcc -E
%__cxx g++
are defined in /usr/lib/macros which is part of the rpm.
If those macros will be removed from this file and moved to
/usr/lib/macros.d/macros.{gcc,clang} it should be possible to provide
the platform which will open the whole spectrum of completely new
possibilities with some minimal changes in whole build env and no
other changes in all specs.
Only weak point in above is how to force use gcc if both gcc and clang
will be installed (which will be quite typical in case all packages
private build envs).
However, I think that even this is a very small obstacle which can be
easily handled.
Now by default %/{__cc} is provided by gcc but if here it will be
introduced small flexible it should be possible to control which
the compiler should be used even if in packagers build system will be
installed both gcc and clang by simple few changes in ~.rpmrc or on
Fedora build systems in ~mock/.rpmrc file.
So maybe instead:
BuildRequires: gcc
better would be to use:
BuildRequires: %{__cc}
or:
BuildRequires: c-compiler
??
if both gcc and clang will have:
Provides: c-compiler
still it will be possible installed gcc and clang without conflicts.
I'm sure that above it is not complete idea and few small bits still
are missing.
I think that we should hold for few seconds and consider change a bit
this proposal to pen those possibilities.
Comments?
kloczek
--
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
