[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tune gcc



On Mon, 17 Mar 2003 ronin2@bellatlantic.net wrote:

> On Tue, 18 Mar 2003 02:35:52 +1100
> Rob Weir <rweir@ertius.org> wrote:
>
>
> >> If setting CFLAGS is the answer, do you need to set all of them, or
> >only> the one you want to change?
>
> > Hm, I don't think I quite got what you meant there...You just set
> > whatever flags you'd set on the command line, anyway...
>
> Suppose:
>  1. I set CFLAGS to <something>
>  2. In a program I want to compile (or its Makefile or wherever) CFLAGS
> is set to <a bunch of things>
>
> Does CFLAGS end up as <something> or as <something plus a bunch of
> things>?
>
> Does my setting add to or replace what would otherwise be set?
>

I don't think there is a blanket answer here for all packages. It really
depends upon how the 'make' system for the specific package is written.
And let me tell you from experience, 'make' is not the easiest program to
learn to use effectively, mostly because it is so capable and there are so
many different ways of getting the same thing done. That all said...

CFLAGS is an implicit variable for 'make' (one of a bunch of them). This
means that a CFLAGS symbol does not have to be explicitly defined in the
Makefile for it to be communicated in the compile command for each
compile. This allows one to set CFLAGS in the environment that make is
called in and get your CFLAGS definition into make and, hence, to the
compiler. make will take the values of variables from the environment and
use them UNLESS the variable is explicitly assigned in the Makefile. If
the variable is assigned in the Makefile, this assignment overrides the
value from the environment. So, if there is no CFLAGS set, then the one
you set will be passed to the compiler, but if it is set, then your value
will have no effect. So I don't think that setting a CFLAGS assignment in
your .bashrc file and then recompiling a bunch of packages will really get
that much.

I think the real answer is to examine the Makefile of the specific package
one is trying to optimize and figure out how to apply the compiler options
necessary to achieve that optimization. This probably isn't for the faint
of heart (from a software engineering point of view). You must be aware
that sometimes optimizations break software, too. It really just all
depends on the specific program. I think that this is the reason that most
knowledgeable people advise to just use the package as provided by the
original developer/Debian maintainer. There could be a lot of effort
involved with getting a little better performance, for not very much
payoff.

Now, in some situations I can see that better performance is worth the
effort. If that is the case, then go for it. That is one of the great
things about Open Source software -- you have the source code and you can
do with it what you want. Modify how it is compiled for your purposes or
do whatever you want. I'd advise that you become pretty familiar with make
and gcc. Just be aware that it may not be that easy and the gains you get
may not be that great.



Reply to: