Makefile.classing enhancements

[alonbl]

Hi,

I got the following[1] request to add this package to Gentoo. It would be great if you can help me a bit.

I do not like system components to use cmake, and it is nice to see that you have classic make.

If you want I can help you port to autotools... but if not, the following changes are suggested to Makefile.classic to ease downstream interaction.

1. Please separate the application specific CFLAGS and the optional CFLAGS.

   Optional CFLAGS are WARNFLAGS, DEBUG, so the following should work without breaking application.

   make CFLAGS="-O3"

2. Please add LDFLAGS to be used when linking.

3. Please add install target and support DESTDIR

   The following sequence should work:

   make CFLAGS="-O2 -march=native -fomit-frame-pointer -pipe" LDFLAGS="-Wl,-O1 -Wl,--as-needed" CC=x86_64-pc-linux-gnu-gcc AR=x86_64-pc-linux-gnu-ar make install DESTDIR=/tmp/root1 PREFIX=/usr LIBDIR=/usr/lib64

Thank you!

[1] https://bugs.gentoo.org/show_bug.cgi?id=432914

[bwalex]

The autotools piece of junk is not getting anywhere near tcplay, but thanks for the offer.

I'd prefer cmake being used for packaging, as its the most robust solution and you get things you don't get with Makefile.classic such as the .pc file. And it seems someone already has packaged it for gentoo with cmake, so I'm not clear on why you don't want to use what works (best).

That said, I've polished the classic Makefile a bit to cater to your needs (hopefully).

I agree it should be possible, but overriding a package's optimization level is generally a pretty bad idea - odds are it is already what it should be.

Fixed in 5b7138a9b7f3ca808ed5042f684145b1a1222918.

[alonbl]

Thank you for your work!

The autotools piece of junk is not getting anywhere near tcplay, but thanks for the offer.

Well, I can say the same about cmake... :)

autotools is far from being piece of junk, most people just don't understand the required complexity of build system to be able to be packaged/repackaged/cross compiled/ported using various compilers/linkage/environments.

But everyone is entitled to own preferences.

And it seems someone already has packaged it for gentoo with cmake, so I'm not clear on why you don't want to use what works (best)

Because I won't maintain cmake packaged file for core infra component. This cmake magic and extra dependencies is not for me to handle and maintain.

Please consider removing WARNFLAGS from the common CFLAGS, and put it per default at the CFLAGS, so it can be overridden easily.... not that important as I can enforce WARN_FLAGS=

Thanks.

[bwalex]

On 28/07/13 15:04, Alon Bar-Lev wrote:

And it seems someone already has packaged it for gentoo with cmake,
so I'm not clear on why you don't want to use what works (best)

Because I won't maintain cmake packaged file for core infra component. This cmake magic and extra dependencies is not for me to handle and maintain.

Fair enough.

Please consider removing WARNFLAGS from the common CFLAGS, and put it per default at the CFLAGS, so it can be overridden easily.... not that important as I can enforce WARN_FLAGS=

I don't see any use case for not having the WARNFLAGS on by default, especially now that I have given up on using -Werror (which on Linux is a complete nightmare, because even the standard headers cause errors).

Cheers, Alex

[alonbl]

I don't see any use case for not having the WARNFLAGS on by default,

If gcc is not the compiler...

[bwalex]

On 28/07/13 15:18, Alon Bar-Lev wrote:

I don't see any use case for not having the WARNFLAGS on by default,

If gcc is not the compiler...

If you aren't using GCC or something that has a GCC-compatible command line (clang) you got bigger problems than some warn flags (you'd have to worry about pretty much every switch, including -c, -o, -Wl,, -D, etc.

And if you are using something like gcc (or clang), then odds are it will have those warn flags. No particularly exotic flags are in there.

Cheers, Alex