Question: should *FLAGS (CFLAGS, CXXFLAGS ... ) for clang (or any LLVM stuff) and gcc (or any GNU stuff) be separately specified in /etc/portage/make.conf ? The problem: Sometimes some packages try to use *FLAGS for i.e. clang , where those *FLAGS were specified by user, who was specifying such flags i.e. for GCC . But there's flags which are supported only by GCC or only by clang . Right now AFAIK usually inside of ebuilds the flags are tried to be stripped. Is stripping a good solution? Pros: - seems to be easy to do - usually good enough Cons: - it obviously strips flags. So, if user specified some flags that are GCC-specific, then usually they are stripped and only what is common for compilation options both for GCC and Clang are kept. - requires editing filter for every compiler-specific flag. What if we could specify specific *FLAGS for GCC and Clang separately? Pros: - no striping, allows keeping compiler specific flags as expected - no `/etc/portage/env` for different compilers. Cons: - IDK how to do it well. The solution for specifying separate *FLAGS via a file at `/etc/portage/env/` has some drawbacks: 1. User need to specify for which package use GCC-specific and for which Clang-specific CFLAGS. 2. For a package that uses tools from GCC and LLVM ( i.e. packages which use XXX (whatever language with LLVM) and fortran : there's no fortran from LLVM in gentoo ), user cannot specify specific flags for different cases. The user is going to strip it by himself. 3. Obviously the need to use `/etc/portage/env` and not specifying once for every general case what compiler to use. Please, assume it's just a question : should it be solved in a way, if yes, what are the ways to implement such behaviour? What can cons be for a solution?
(In reply to Arniii from comment #0) > The solution for specifying separate *FLAGS via a file at > `/etc/portage/env/` has some drawbacks: . > 3. Obviously the need to use `/etc/portage/env` and not specifying once for > every general case what compiler to use. sry, I meant 3. Obviously the need to use `/etc/portage/env` and not specifying once in `/etc/portage/make.conf` for GCC and LLVM.
In general, I would say that packages that force a specific compiler should run `strip-unsupported-flags`.
(In reply to Sam James from comment #2) > In general, I would say that packages that force a specific compiler should > run `strip-unsupported-flags`. Indeed, I'd say it's a bug if toolchain gets changed and this isn't ran. That's enough to prevent unexpected failures in most cases and if you do want more control anyway there's package.env (not enough packages do this that we need a global solution I think).
I thought what if ask user to specify different *FLAGS for different compilers right in `/etc/portage/make.conf` , i.e. `CFLAGS` -> `GCC_CFLAGS` and `LLVM_CFLAGS` But I genuinely don't know how make packages aware of this. (In reply to Ionen Wolkens from comment #3) > not enough packages do this > that we need a global solution I think It's true. Though these packages exist. Maybe there's an easy way you know how to find what packages specify toolchain that is different from what is expected on profile? I know that if try build GCC on clang profile, there will be a good portion of stripping at some stages. But IDK how to solve it via `/etc/portage/env` (and should it be solved?) , because the stripping can remove some flags that are clang-specific for specifying a target i.e. -mmx or -glldb Or like here graphite flags for a meson's test: https://bugs.gentoo.org/938133 Or like gdb
I just don't really see a need for it at present because the ebuilds should use `strip-unsupported-flags` if they force a separate toolchain, and if you're doing it instead but the ebuild requires something else, you should probably do package.env tweaks. The other issue is that GCC_CFLAGS and CLANG_CFLAGS isn't enough, a bunch of the issues when toolchains get overridden for a few special cases involve cross or similar or where the user flags often need to be severely stripped anyway. For that Meson issue, that needs analysis still, but testing build systems is often kind of interesting anyway because they need to try a bunch of alt configurations and may not expect some of the things a user set. Please provide specific examples (not just the meson one, as that hasn't been analysed). GCC I would argue is also a special case and actually has its own problems with cross if certain things like CC are in make.conf as opposed to letting it pick up defaults. Not seeing anything yet which justifies or motivates a general solution beyond what was already said.
