On Mon, 17 Mar 2003 [EMAIL PROTECTED] wrote: > On Tue, 18 Mar 2003 02:35:52 +1100 > Rob Weir <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
