Created attachment 375308 [details] aegisub-3.1.2:20140419-165151.log two layers here: 1. adds -O3, -pipe and -g 2. does not respect CFLAGS in linking command
Created attachment 375310 [details] emerge.info.txt
https://github.com/Aegisub/Aegisub/blob/master/configure.ac#L147 AC_ARG_ENABLE(compiler-flags, AS_HELP_STRING([--disable-compiler-flags],[Disable *all* additional compiler flags. [no]])) Not sure if building with '--disable-compiler-flags' is officially supported by upstream.
(In reply to Nikoli from comment #2) > https://github.com/Aegisub/Aegisub/blob/master/configure.ac#L147173 > AC_ARG_ENABLE(compiler-flags, > AS_HELP_STRING([--disable-compiler-flags],[Disable *all* additional compiler > flags. [no]])) > > Not sure if building with '--disable-compiler-flags' is officially supported > by upstream. who cares? Most don't even know what they are doing with their flags hacking.
(In reply to Nikoli from comment #2) > https://github.com/Aegisub/Aegisub/blob/master/configure.ac#L147 > AC_ARG_ENABLE(compiler-flags, > AS_HELP_STRING([--disable-compiler-flags],[Disable *all* additional compiler > flags. [no]])) > > Not sure if building with '--disable-compiler-flags' is officially supported > by upstream. You can do what we do in other packages by introducing the custom-cflags to allow overrides in the upstream CFLAGS.
(In reply to Markos Chandras from comment #4) > (In reply to Nikoli from comment #2184) > > https://github.com/Aegisub/Aegisub/blob/master/configure.ac#L147185 > > AC_ARG_ENABLE(compiler-flags, > > AS_HELP_STRING([--disable-compiler-flags],[Disable *all* additional compiler > > flags. [no]])) > > > > Not sure if building with '--disable-compiler-flags' is officially supported > > by upstream. > > You can do what we do in other packages by introducing the custom-cflags to > allow overrides in the upstream CFLAGS. Yes, or something like "--enable-minimal-flags" for autotools, see https://github.com/hexchat/hexchat/commit/19d435648443bc0dc7a1a4058de1eeb79730d809 for an example
in cmake you can do something like option(MINIMAL_FLAGS "Respect system flags as much as possible (off)" OFF) and then just embed all optimization-specific code inside if(MINIMAL_FLAGS) ... endif(MINIMAL_FLAGS) but if you are lucky, they just changed build-type specific flags which you can just set to an empty string
> who cares? I do. It is better to cooperate with upstreams and respect their opinions and suggestions. > Most don't even know what they are doing with their flags hacking. And it often leads to breakages or slowness and spamming upstreams with invalid bug reports. > You can do what we do in other packages by introducing the custom-cflags to allow overrides in the upstream CFLAGS. Sound like a plan, i think adding USE custom-cflags that when enabled will add --disable-compiler-flags to configure command should fix this bug.
(In reply to Nikoli from comment #7) > > who cares? > > I do. It is better to cooperate with upstreams and respect their opinions > and suggestions. > Erm, so do I. I try to upstream all of my patches for my own packages. I wrote bug reports for nvidia and intel even. Guess if I got a response. I have yet to see one upstream that doesn't just hack CFLAGS for their own development purposes. That is pretty common. Not everyone runs a source ricer-distro. So most upstreams don't even expect people to compile that stuff on their own. Also, I highly doubt that "-O3" is any safer than "-O2". "-g" clearly violates our policy anyway and "-pipe" is just minor. That said, our own QA standards are more important than upstreams opinion like "but it runs faster with -O3". > > Most don't even know what they are doing with their flags hacking. > > And it often leads to breakages or slowness and spamming upstreams with > invalid bug reports. > > > You can do what we do in other packages by introducing the custom-cflags to allow overrides in the upstream CFLAGS. > > Sound like a plan, i think adding USE custom-cflags that when enabled will > add --disable-compiler-flags to configure command should fix this bug. custom-cflags is mostly an invalid USE flag USE flags should only be added if they actually affect the build like additional code paths, additional files installed and so on. Not plain dependencies or flag magic (mostly). However, it is sometimes used in cases like libsdl2 where we KNOW that custom cflags break stuff. It's not meant as "better introduce this right from the start". That would be just wrong.
any progress here?
I'll do my best to fix this bug together with bug #536244. There are PRs related to this issue available at the upstream GitHub page ([0], [1]). I am going to use them as a starting point. [0]: https://github.com/Aegisub/Aegisub/pull/34/files [1]: https://github.com/Aegisub/Aegisub/pull/29/files
perfect
(In reply to Ian Delaney from comment #11) > perfect marvellous even
Done. See URL for PR. After PR is (hopefully) merged this bug will be closed.
Fixed in 3.0.4, 3.2.2, 9999.
commit c2677e5cfc8e1dd211890be4159fc5d604e9b434 Author: Ilya Tumaykin <itumaykin@gmail.com> Date: Mon Nov 2 11:26:28 2015 +0300 media-video/aegisub: version bump to 3.0.4 Add the last aegisub version that has: - dependency on <wxGTK-3.0 - no dependency on boost - no dependency on icu - optional libass dependency - optional lua dependency It also has the similar changes as 3.2.2 ebuild: - proper compiler flags handling - minor lua issues fixed - cleaned up dependencies commit d7a9183983102c049cd410692cb8f7e8c7073f79 Author: Ilya Tumaykin <itumaykin@gmail.com> Date: Mon Nov 2 11:34:10 2015 +0300 media-video/aegisub: version bump to 3.2.2 Inherited from Nikoli. List of changes compared to Nikoli ebuilds: - respect user compiler flags - do not enable debug flags for regular builds - omit unneeded ancient version numbers in deps - unbundle luajit - fix minor lua issues - check for C++11 compiler support - remove virtual/glu dep as it was only needed for crashreporter, which was never finished and ultimately was removed upstream - avoid nls USE as build system expects config.rpath file being available regardless of the value of nls configure option Gentoo-Bug: 536244 Gentoo-Bug: 508120