retitle 1041367 Automate GCC version handling. # tag with patch as a merge request is available. tag 1041367 patch thanks
Manphiz <manp...@gmail.com> writes: > Sean Whitton <spwhit...@spwhitton.name> writes: > >> Hello, >> >> On Mon 17 Jul 2023 at 07:26pm -07, Xiyue Deng wrote: >> >>> Currently Emacs hard-codes the GCC version - more specifically the GCC >>> JIT version - for the native compile feature. As the default GCC >>> version may change once in a while, it may be beneficial to avoid >>> hard-coding the version and instead generate it using default GCC. I >>> have prepared a merge request on salsa[1], however as inexperienced as I >>> am this will surely look crude, but may be an okay-ish start of >>> discussion. Thanks! >> >> Thank you for looking into this. Unfortunately, I think it's unlikely >> that we'd want to apply this change: typically things like this are done >> manually in Debian. It's similar to debhelper compat level bumps. > > Thanks Sean! I understand. Would it be acceptable to have things > slightly automated while still make the GCC version hard-coded? Like > having a variable "default_gcc_version" which is manually changed and > the rest auto-generated? On further testing, it look like the automatic GCC version detection I proposed is indeed problematic: as the file regeneration happens before a buildd is involved, the generated version depends on the system that the people tries to build it. So as I'm currently using a stable system, when I run `gbp buildpackage` it will detect the GCC version as 12 while on sid it's 13 which is a nightmare. So, I've reworked the MR a bit now that it still hard-code the GCC version but at a single location[1] and all versions at other places are generated so that it's less like to make mistakes. Please help take another look. Thanks! [1] https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/3/diffs#8756c63497c8dc39f7773438edf53b220c773f67_74_75 -- Manphiz
