Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 508120 - media-video/aegisub does not respect CFLAGS
Summary: media-video/aegisub does not respect CFLAGS
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Coacher
URL: https://github.com/gentoo/gentoo/pull...
Whiteboard:
Keywords:
Depends on: 508812
Blocks:
  Show dependency tree
 
Reported: 2014-04-19 17:00 UTC by Julian Ospald
Modified: 2015-11-03 09:54 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
aegisub-3.1.2:20140419-165151.log (aegisub-3.1.2:20140419-165151.log,147.13 KB, text/x-log)
2014-04-19 17:00 UTC, Julian Ospald
Details
emerge.info.txt (emerge.info.txt,6.01 KB, text/plain)
2014-04-19 17:01 UTC, Julian Ospald
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julian Ospald 2014-04-19 17:00:32 UTC
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
Comment 1 Julian Ospald 2014-04-19 17:01:14 UTC
Created attachment 375310 [details]
emerge.info.txt
Comment 2 Nikoli 2014-04-20 05:50:39 UTC
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.
Comment 3 Julian Ospald 2014-04-20 11:21:14 UTC
(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.
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2014-04-20 11:23:01 UTC
(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.
Comment 5 Julian Ospald 2014-04-20 11:27:22 UTC
(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
Comment 6 Julian Ospald 2014-04-20 11:42:55 UTC
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
Comment 7 Nikoli 2014-04-20 12:44:55 UTC
> 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.
Comment 8 Julian Ospald 2014-04-20 13:11:17 UTC
(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.
Comment 9 Julian Ospald 2014-07-04 19:42:32 UTC
any progress here?
Comment 10 Coacher 2015-10-27 14:43:44 UTC
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
Comment 11 Ian Delaney (RETIRED) gentoo-dev 2015-10-28 00:24:09 UTC
perfect
Comment 12 Julian Ospald 2015-10-28 00:26:07 UTC
(In reply to Ian Delaney from comment #11)
> perfect

marvellous even
Comment 13 Coacher 2015-11-02 09:02:43 UTC
Done. See URL for PR. After PR is (hopefully) merged this bug will be closed.
Comment 14 Coacher 2015-11-03 09:45:54 UTC
Fixed in 3.0.4, 3.2.2, 9999.
Comment 15 Ian Delaney (RETIRED) gentoo-dev 2015-11-03 09:48:28 UTC
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