-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Sun, 2018-02-18 at 20:36 +0000, Tomasz Kłoczko wrote:
> 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 :-/
I didn't introduce any changes, I just made mass rebuild and asked people to
fix their packages.
> Here is the copy of my yesterday reply:
I have seen it, but as usual with your messages (which are very long and mix
different things) I stopped reading after second paragraph..
> 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.
Yes, theoretically. I think the real reason is because we want explicitly to
use GCC and nothing else.
> 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.
Actually csmock already can do that. Probably not in very nice way, but it
works.
> 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.
Are you willing to work on Guidelines Draft for FPC on this? Right now I just
want to get rid out of gcc/gcc-c++ in buildroot and I chose following
**existing guidelines** as a base for this while what you are proposing
requires coordination with FPC.
I'm not against this idea at all, but this is totally outside of scope of this
change. In any case, once we will have necessary BuildRequires all over the
place we can easily replace them with whatever we will decide is correct.
- --
- -Igor Gnatenko
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqJ54AACgkQaVcUvRu8
X0zGLBAAuOA1jXfXJFdOaqhsTDBeANpTpS7zwFOZmbBpuAAq6cVpWyAcaGiJwNiE
EBYvpUJKZsSoVAMP4E2rneKnjgje9TAA8/ccpcrmv8b8iBf4qyx/uwEJIo3skFpB
qcOonXZamMm4v/afb1rVWbG6ogKS+1TPZ3YN/N8iaie8XHt4s/jcla/Miv3Yz6Gv
Y9NwzOQ8kkYr5Z6hVwWs07kjZHbkccaAa7u218Gho2hlhPLrhguKXm3SvcfQETit
F5wBeyxDPgAdNLhsDwXeeIYeClJsj91Z7YDCyfPZaB9vKMuap/dHsz/GWtT7kLNW
RaLlci0K0ElCx/Y/Ogdjk64su3//TkIjVRVG3fcPfqAu7bO7C7rvO3VFEAeYcqeP
K/ZQ39rbqs7vADPu5FgWnWE+Wryddh843Y7m7Qo1yj+G+/JXrX0dkl6a++mtiz/E
OVaq+sGiwnQOYtygRoLQ3a9jKduLOwAx8V7ghnUFnuZqOUy3XmHPJfAM9Htb0XWt
jpNBHo5BL/vM66QcNFrSPO/OiVwYnCrCMkKYPgPhWK7RGR1dmB+5lk2B8GTeuhwt
525iOfu2ivfU84oOoZXiXKbJPufRtWeg9cAwWJ3bGoKEEz9KLVBlQXilOWwTSBkb
faTPfcn9dD3LL4oH78ladalsb0f7qAZGgozsm2lBTR+9bTqJQT8=
=Ll0I
-----END PGP SIGNATURE-----
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
