Arch Linux

This means a distribution will never provide debug packages.

Don't. But how are you going build and install a debug package to provide a debug information to maintainers?

I.e. it's not even means of distribution, but rather of a simple package management.

You have a choice. Fully functional debug packages built without any optimisation. Or partially functional debug packages that have optimisations matching (and hence work with) the released binary.

> This means a distribution will never provide debug packages.

See, I just hacked that around by setting

CFLAGS=""
CXXFLAGS=""
LDFLAGS="-Wl,--sort-common,--as-needed,-z,relro"

in the beginning of the PKGBUILD file, so I'm only getting "DEBUG_*" flags. Hence by no way that would stop anyone from distributing debug packages.

But with disregard, if there's an option "debug", then it is meant to be used. Otherwiser it wouldn't have been added to makepkg in the first place.

Yes it would... those debug packages will no linger work with the optimised binaries that people distribute.

This bug is ridiculous.

CFLAGS="flto -march=native -mtune=native -O3 -pipe -fno-stack-protector"
DEBUG_CFLAGS="-g3 -Og"

Did you even read the gcc manpage or google "gcc override optimization" before filing this pointless bug?

> Did you even read the gcc manpage or google "gcc override optimization" before filing this pointless bug?

First, there's no documentation about in what order DEBUG_*FLAGS and common *FLAGS are passed. Second, why should I care to neutralize my -flto from optimized build with -fno-lto, and why should I care to check every option to make sure I neutralized it in the debug options? THIS is ridiculous.

Dude, why are you chasing me everywhere in attempts to find some mistake? If you want me to accept you're smart — here you go: you're smart. Now please stop.

https://github.com/lxde/pcmanfm-qt/issues/627 I ran across this while researching the background of  FS#56836  in order to understand the issue and triage that bug. Somehow, your workaround for something that doesn't need to be worked around, led to your being unable to compile a debug build with makepkg when one of the upstream developers managed it just fine (and presumably the only thing that you did differently was use a modified makepkg.conf that maybe did some ill-advised bash).

As an official Arch Linux bug wrangler and sometimes makepkg developer, I take a proprietary interest in things, and also I like to offer practical solutions to problems.
I also feel it is important to note for the record (and for future googlers etc.) that this isn't *just* a WONTIMPLEMENT, but also something that has a much better solution that has always worked.

You can of course neutralize whatever you choose, and I guess it would usually be easier to neutralize a few options rather than copy-paste and add a greater number of options that give you meaningful non-debugging related modifications. Unless your CFLAGS line is primarily a long list of optimization instructions, in which case you're really not the average use case, and we're not going to change how makepkg works to convenience you when it means inconveniencing *everyone* else...

> First, there's no documentation about in what order DEBUG_*FLAGS and common *FLAGS are passed.

You must not have read the makepkg.conf documentation any more than you read the gcc documentation. The initial commit that added DEBUG_*FLAGS also added the documentation stating the following: "Additional compiler flags appended to CFLAGS for use in debugging."

Note the word "appended", which is a subtle indication that they are appended, not prepended.
Also note that this is part of the documentation you insist does not mention any such thing.
Also note that no one else has ever had your issues (or at least hasn't told us so), probably due to the fact that they read the first sentence of the documentation for the relevant feature.
Note how none of this requires me to be "smart", it just requires me to read the documentation which you implied you did when you asserted that the documentation does not include $detail. If that is the current criteria for being smart, then an awful lot of people are smart (but unfortunately not you).

> You must not have read the makepkg.conf documentation any more than you read the gcc documentation.

Well, this time you turned out to be right, there indeed is this line, although I don't see where your reference about me not reading gcc docs comes from. Aren't you're referring to your suggestion to override flags which I both knew and answered?

> You can of course neutralize whatever you choose, and I guess it would
> usually be easier to neutralize a few options rather than copy-paste and add
> a greater number of options that give you meaningful non-debugging related
> modifications.

What would be easier is to add a switch to makepkg to ignore flags in CFLAGS and CXXFLAGS.

> Also note that no one else has ever had your issues (or at least hasn't told us
> so), probably due to the fact that they read the first sentence of the
> documentation for the relevant feature. Note how none of this requires me to
> be "smart", it just requires me to read the documentation which you implied you
> did when you asserted that the documentation does not include $detail. If that
> is the current criteria for being smart, then an awful lot of people are smart
> (but unfortunately not you).

Jesus Christ, you found one single mistake, but it feels like you discovered Atlantida instead.

Also note that I also have built dozens of packages the way I'm using, and this problem happened to me for the first time.

Eli Schwartz (eschwartz) now let me spoil your celebration a bit, consider that I did not build debug package, but instead some common package with very specific flags. You know, development may happen in surprising ways, so I might as well want to add `-I` option to some custom include that is not at /usr/include. Passing it for pcmnfm-qt would result in build fail.

If you pass broken includes to software, you can break it regardless of what else you do, so I'm not sure I see what that has to do with the whole concept of debugging, let alone this pacman feature.

You can hardly expect people to see you say "oh, CXXFLAGS" aren't being detected, and somehow magically know that the real issue is that CXXFLAGS were detected but contained a poisonous option that broke compilation at the most basic level -- at least, I assume that is what your comment is getting at? Not sure what that has to do with lto though.

I cannot imagine an include directory that would be added to global CFLAGS rather than in the PKGBUILD, anyway.

And no we will not add a switch to ignore CFLAGS. Next thing you know, someone else will ask for a special flag to turn on -march=native optimizations, another person will want a flag to run lto/pgo (with multiple makepkg runs to boot), etc. We'd quickly end up drowned in flags for fringe cases and things that are better configured via the standard, normal methods.

Requiring someone who wants to use debug builds to modify their configuration file to enable debug builds and then apply a flag on the command line to make debug builds work as expected, is silly when you could just write the configuration file correctly in the first place.

And because of responding to a bug that was closed for over a year, I have now disabled comments on closed bugs...