On Tue, 2005-09-27 at 19:38 -0600, Brian wrote: > We have several files which are not able to be optimized, and when our mac > mini tries to build the project it chokes up when attempting to do so. It > seems incorrect to say that the package developer is the least qualified to > judge compiler flags, Sorry, but experience tells he is - a developer's view and knowledge are very limited.
Normally, a developer only knows about the problems he is facing on his development platforms. Additionally, he might have received a couple of reports from people using other development platforms. So he might have some ideas on particular problems on a set of platforms he doesn't have access to. > and it also seems to avoid the point. The package > developer should be able to override the autotools, and the user should be > able to override the developer. The point is: Technically, package developers can override the autotools, if they really like to, however in most of all such cases they will not be able to do so, because though developers think they know what they are doing, they do not actually know it. >From my experience, in 99% of all of such cases, developers trying to set up CFLAGS/CXXFLAGS end up outsmarting themselves. For example: Harald wants to override -O2 a) to work around a compiler bug b) because the compilation speed/optimization ratio doesn't seem worth it. wrt. a): He would have to detect if the compiler is affected by the bug and how to work around it. What he actually knows is that "i386-redhat-gcc-4.0.1-20050731 -O2" as shipped with "Fedora Core 3 updates as of 20050920" causes a segmentation fault with a particular code example and that the same example doesn't segfault with -O2. He probably doesn't know how the same compiler behaves on other architectures, nor does he know how other compilers behave on other hosts/OSes. I.e. he doesn't know the actual origin of the problem and therefore can't actually provide a work-around. All he can try is to reduce the likelihood of hitting this issue. wrt. b) His decision is based on personal observation on his development machines and targets, but he has no chance to know about how this situation is on other platforms. * Compilation speed on an i386 w/128MB RAM will be completely different from that on an N-processor SMP sparc-development host w/XX GB RAM * Compiler memory requirements will be different on different development haost * The object sizes for i386 targets will be different from that on sparcs. * The "optimal compiler flags" for GCC will be different from that for a commercial compilers. So all autoconf and the developer do here, must be somehow wrong/sub-optimal somewhere. The only person to answer these questions for a particular host is the "system integrator", i.e. the package's user. > It is not a matter of qualification, it is a > matter of the chain of command. It is - It is a matter of personal knowledge. For example: You seem to know about a particular problem on something called "mini mac", a platform I have never seen nor used before. I know about problems on platforms I use and you probably never have heard about before. We both probably have no idea about what might be required on other platforms. I.e. you in your role as "user/system-integrator/packager" will be able to supply work-arounds for your "mini mac", while I am able to provide work-arounds for my target platforms. Ralf
