build system fixes

[hasufell]

remove getver.sh and handle it inside the Makefile (also overwritable by user) set programs properly and allow user to overwrite with non-PATH stuff respect CFLAGS, CC and LDFLAGS (only add flags that are crucial for compilation) add option for -DENABLE_NLS=1 remove stripping if debug is disabled and handle it via "make strip" use LIBS instead of LDFLAGS to add libraries add ncurses pkg-config calls reorder the compiler/linker line properly

[clbr]

• my ncurses did not come with a pkg-config file, that would fail the build here
• moving getver.sh to make + echo seems needless churn
• I want the sections flags there to make small binaries, that's why they're there in the first place ;)
• some of that moving to variables is completely overboard, IMHO, like $(RM)

I'll pull the parts I agree with ASAP.

[clbr]

Oh and thanks! I hope that wasn't too harsh.

[hasufell]

"my ncurses did not come with a pkg-config file, that would fail the build here"

• that is a bug in your distribution then, because upstream provides them (compile with --enable-pc-files)

"moving getver.sh to make + echo seems needless churn"

• I don't understand why you wrote a script for that in the first place. That also means I cannot use "make VERSION="something"" which makes redistribution more difficult and needlessly adds git-dependency to that package if I don't want "unknown" version. On top of that compilation fails if ".git" directory is not existent btw which applies for github-generated tarballs. Also... some package managers don't store git-repos (including .git dir) where they do compilation. For those it will also fail/need workarounds/extra work.

"I want the sections flags there to make small binaries, that's why they're there in the first place ;)"

• I reccommend to set them in your system, not hardcode them in Makefile, otherwise every downstream gotta fix it.

"some of that moving to variables is completely overboard, IMHO, like $(RM)"

• probably... just did it for consistency.

[clbr]

"that is a bug in your distribution then, because upstream provides them"

• They didn't use to, and I don't have the latest ncurses installed.

"That also means I cannot use "make VERSION="something"""

• On purpose, I don't want a plethora of custom version strings

"On top of that compilation fails if ".git" directory is not existent btw which applies for github-generated tarballs."

• Already fixed

"I reccommend to set them in your system, not hardcode them in Makefile, otherwise every downstream gotta fix it."

• No point in setting them system-wide, when I only want them on some binaries. The only downside to them is that they introduce a version dependency on binutils 2.18, so on most current systems, there is nothing to fix. BTW, do you (/gentoo) also remove those flags from all other packages defaulting to them, for example busybox?

rm and a2x are system-independent, so using the host versions in case of cross-compiling doesn't hurt.

Anyway, please check current master, if there still are things lacking, please rebase your fixes.

[clbr]

In current master there is no more dep on git, for example. There may be "proper" tarball releases in the future when things stabilize a bit.

[hasufell]

"On purpose, I don't want a plethora of custom version strings"

• if I use the git-tags I can rely on a certain version and set that within package manager mechanisms without having to rely on git or some script. There won't be a mismatch. That has nothing to do with custom and we will do that downstream anyway. Also, it preserves the existent functionality of your script.

"They didn't use to, and I don't have the latest ncurses installed."

• as I said... you probably did not compile with "--enable-pc-files"

"No point in setting them system-wide, when I only want them on some binaries. "

• I didn't mean system wide, set them for that package. Your distribution should provide mechanisms for that or do `make CFLAGS="..."'

"BTW, do you (/gentoo) also remove those flags from all other packages defaulting to them, for example busybox?"

• we remove flags that are not needed for compilation. Flags should be handled by the user/redistributor. Hardcoding unneccessary flags just results in endless patching which we do every day. however ... CFLAGS ?= -Os is fine, cause it only applies if there are no CFLAGS in the envrionment and will set some defaults for people that manually compile without caring about flags and settings. But CFLAGS += will unconditionally add them which is undesired.

"Already fixed"

• thanks

[hasufell]

how about we do the following:

$(shell pkg-config --libs ncurses 2>/dev/null || echo "-lncurses")

that should work

[clbr]

That's what I did in commit 0c3f239394b yesterday?

[hasufell]

oh, completely missed that :D

[hasufell]

else CFLAGS += -s endif

Is a very weird way to force stripped binaries over the user and ignore anything he might have set via his system/environment. IMO it should not be set at all in a Makefile. Makefiles should provide a "strip" or a "install-strip" rule for that like autotools.

There is still no option for nls, simply ifdef nls CPPFLAGS += -DENABLE_NLS=1 endif

would work (or do the reverse thing if you want it default). Please describe all available options at the top of the Makefile, cause we don't have a configure file here.

[hasufell]

LDFLAGS += -Wl,-O1 -Wl,-gc-sections

ldflags are still hacked, please do

LDFLAGS ?= -Wl,-O1 -Wl,-gc-sections

which will respect the systems/env LDFLAGS if present.

[clbr]

nls option & option comments added.

On ldflags additions, I want this binary to be sectioned. As mentioned above, those flags are completely safe.

[hasufell]

-ffunction-sections and -fdata-sections should not be forced on the user

http://blog.flameeyes.eu/2008/01/today-how-to-identify-unused-exported-functions-and-variables

[clbr]

Yes, I have read that article before, and I disagree with its premise.

It advocates a ton if ifdefs instead, which in any configurable app would quickly become unmaintainable.

[hasufell]

would you mind if you use seperate variables for those CFLAGS_EF = -ffunction-sections -fdata-sections CFLAGS += $(CFLAGS_EF)

LDFLAGS_EF = -Wl,-O1 -Wl,-gc-sections LDFLAGS += $(LDFLAGS_EF)

this would allow me to overwrite it via make LDFLAG_EF="" CFLAGS_EF="" without patching/sedding which makes it easier to maintain.

[clbr]

Yeah, that'd work. I'd like to hear why you object to -O1 to the linker though?

It's documented to either have no effect or an improvement, and recommended to always apply unless in need of fast builds.

[hasufell]

LDFLAGS are handled globally in gentoo (the user can also apply different ones for single packages via environment settings) and other source distros I know of. That means they generally don't want any kind of flags that are not needed for the package in order to compile except they greatly enhance/speed up the compiled binaries/libraries and cannot be set globally (like the section stuff). The section thing here is debatable and I don't have a strong opinion on it either, but making it overwritable is nicer imo.

As for the O1 thing it should rather be:

CFLAGS_EF = -ffunction-sections -fdata-sections CFLAGS += $(CFLAGS_EF)

LDFLAGS ?= -Wl,-O1 LDFLAGS_EF = -Wl,-gc-sections LDFLAGS += $(LDFLAGS_EF)

this will set -Wl,-O1 if there are no LDFLAGS in the system/env, but add -Wl,-gc-sections unconditionally unless the user unsets them on the make-line

[clbr]

Added.

[hasufell]

Thank you!

The last thing that's bothering me is the handling of stripping, could you elaborate why you don't just add a "install-strip" rule for that? Otherwise this will mess up system-internal handling of binary stripping.

[clbr]

Simply a matter of dev convenience, unless I'm debugging, I want stripped.

Seems Debian does a debug build, perhaps Gentoo could too? Is there some separated debuginfo packages, etc complicating things?

[hasufell]

I don't understand, gentoo does not pre-build packages. The user handles his (debug) flags almost alone, because no upstream can anticipate what he actually wants. We only provide a debug useflag if there are actual in-source switches which change behavior of the program and even then cflags will be filtered. For dev convenience you could use gentoo where you can manage your flags properly without touching build systems.

But talking generally... not every user will expect stripped binaries if he does not use your debug option. That's just your workflow and shouldn't be forced on the user.

This will require a patch downstream. Autotools offers a "install-strip" rule as already mentioned which does the exact same thing without doing unexpected changes/additions to flags.

[clbr]

Heh @ the conversion attempt. I'm stable in my religion, thank you.

Sorry, dev convenience > user convenience, every time. What autotools does may be de-facto standard, but it's not necessarily the best way.

[hasufell]

there is also "packager convenience"... sometimes packagers get lazy because of trivial issues they don't want to bother with on every version bump and then forget to package something...

at least include a "nostrip" option:

https://gist.github.com/3560567

[clbr]

Perhaps you could enlighten me why you want such a binary in the first place?

The limited symbol list is not useful for debugging/backtraces.

[hasufell]

No, you didn't understand... as I already said most proper source distros handle these things on their own which means: a) stripping is handled system internally and is fine-grained, your Makefile breaks this control b) debug flags are handled by the user, not by some random flags the Makefile adds. There is more than one debug flag btw., but you don't offer the choice. c) gentoo offers a "split-debug" option which again requires Makefiles not to mess with such things, cause they should not at all.

As a sidenote: if you would have used autotools we could have saved quite some time.

[clbr]

If I used autotools it would have taken more time for me, plus I would have done a similar change there too (strip by default) anyway.

To be clear, I don't care how advanced and fine system Gentoo has - I don't use Gentoo. This thread is going nowhere, closing.

[clbr]

To clarify, this is bikeshedding over a policy decision.

I suggest to simply always use the debug option, not exposing that as an use flag. Since you strip separately, it should work out.

For more debug options (-ggdb etc), they can be added to normal CFLAGS as usual, gcc will do the right thing.

[hasufell]

This is not just gentoo related. Any source distro handling compiler flags (I was not talking about useflags) and stripping on their own (which is the only proper way, cause you cannot have everything in scope they do or need to do) will conflict with this.

Proper build systems already know that.

What you suggest is just insufficient and blocks radentop from being distributed (at least by me). Thanks for merging some of the proposed changes anyway.