Re: git: 06601897e5cd - main - framework: reintroduce the feature enabling code
Date: Sat, 13 Jul 2024 14:30:31 UTC
On Sat, Jul 13, 2024 at 02:04:48PM GMT, Daniel Engberg wrote: > On 2024-07-13T08:47:47.000+02:00, Mathieu Arnold <mat@freebsd.org> > wrote: > > > On Sat, Jul 13, 2024 at 06:11:04AM GMT, Daniel Engberg wrote: > >> Hi, > >> > >> This changes so LTO option is no longer applied to Rust (cargo) > >> ports > >> > >> BY DEFAULT causing a regresssion, please fix. > > > > As it has been three months, nobody complained something was broken > > so, > > > > I don't think anything is actually broken. > > > > LTO as are a few other features like SSP are user facing features, > > not a > > > > porters facing options, it means, it's up to the person doing the > > > > building to choose wether to enable it or not, it is **not** up to > > the > > > > person porting the software to forcefully enable it. > > > > -- > > > > Mathieu Arnold > > Hi, > > Likely because this pretty much silently went by because it was posted > on Phab and you only CCed bapt. It's been enabled since Jan 2023 > (https://cgit.freebsd.org/ports/commit/Mk/Uses/cargo.mk?id=967022fd812cf67dec264ee4e53bd016b69e7a2b) > and tested/discussed here https://reviews.freebsd.org/D36736 before > being enabled/committed. I noticed it now while updating a Rust > (cargo-based) port. Mmmm, yes, I know about that, and I agree, this commits reverts this behavior. Because choosing to build with or without LTO is a user facing feature, not a porter facing feature, so, it has to be set by people building the things, not by the framework or a port. -- Mathieu Arnold