compiler-flags

问题 With Xcode 4.2 and the LLVM compiler, when compiling for ARMv6 there are some very weird bugs in the generated application (such as "width" property of CGSize returning the "height" instead). To fix this, I found I must set the compiler flag -mno-thumb. I know how to set compiler flags on a file-by-file basis, but is there a way to set a compiler flag for the entire project? 回答1: You can set project wide compiler flags in the project settings under the "Language" section of the "Build

问题 Does exist a variable which contains the compiler flags used in some call to CMake's ADD_LIBRARY function, for example the ones used when we add a module: ADD_LIBRARY(mylib MODULE mysrc.cpp) Or, is there a way of getting such flags? 回答1: Turning my comments into an answer There is not a single CMake variable to get the all compiler flags. The problem is that the CMake generator will finally put together the compiler flags (from various CMake variables and properties incl. from depending

问题 So I have a moderately complex set of requirements for my worker processes. I want to use a the master slave topology, and a nondefault working directory. I also want to mix both local and remote workers. As far as I can tell from readying the --machine-file section of the documentation. It will not let me do that. So I am looking at the -L <file parameter >julia -h ... -L, --load Load immediately on all processors ... So if I do not use the -p or --machine-file` flags, then there is

问题 I'm using CMake, and I want to add a compilation flag to some flags variable. For example, I want to add -DFOO to the CMAKE_CXX_FLAGS_RELEASE variable. Right now, I use: set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -DFOO" ) ... but if there already is a -DFOO flag, I get it double, which might be harmless but I'd rather avoid it. Assuming I can't control whether or not there's a -DFOO to begin with - how can I "add a flag only if it's missing" to such a flags variable? Notes: An

问题 Is there any way to rewrite either: flag llvm description: compile via LLVM default : if os(mingw32) False else True or flag llvm description: compile via LLVM default : True if os(mingw32) ?SET-LLVM=False? and get cabal to work with it? Note: Further down in the same file the llvm flag is used like: if flag(llvm) ghc-options: -fllvm -optlo-O3 and there are many other single high-level flags that translate to multiple ghc-options entries, such as static to -static -optl-static . 回答1: You can

问题 No matter what I try, like adding the compiler flags -fno-exceptions -fno-rtti , I always get these exception-handling functions in my shared objects: Image This happens whether I compile as C or C++. It happens with these includes (compiled as C++ - haven't tried to compile as C): #include <jni.h> #include <math.h> #include <stdint.h> #include <stdlib.h> #include <string.h> Here are all of my includes for the one I have compiled as both C and C++ (most/all of them aren't needed for the

问题 I just read this post about why new-line warnings exist, but to be honest my team has people working on several different platforms and with several different editors (everyone uses what bests suites them), so the warning has become ubiquitous, and since its not really a warning worth taking care of it's become noise and makes finding serious warnings a hassle. Many times important warnings have gone unnoticed because, people got used to having a gazillion useless warnings pass by, so they

问题 I learned from chapter 9 of Learn You A Haskell For Great Good that By convention, we don't usually specify a type declaration for main . As far as I can tell, this convention is widespread. However, if I compile, using the -Wall flag, a program that lacks a type signature for main , such as -- test.hs -- main :: IO () main = print (1 :: Int) GHC does issue a warning: $ ghc -Wall test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:2:1: Warning: Top-level binding with no type signature

问题 Like many, I build my project with the an abundance of warning flags. Since not all warning flags are detrimental, the compilation becomes noisy. Warnings such as "unused variables", "shadowing members in initialization lists", "missing switch defaults", are all important to log, but they create too much clutter during builds, and it is hard to spot the important warnings. Given a large project, there can be thousands of warnings mixed in with build statements, and parsing though it

问题 This question is related to this one as well as its answer. I just discovered some ugliness in a build I'm working on. The situation looks somewhat like the following (written in gmake format); note, this specifically applies to a 32-bit memory model on sparc and x86 hardware: OBJ_SET1 := some objects OBJ_SET2 := some objects # note: OBJ_SET2 doesn't get this flag ${OBJ_SET1} : CCFLAGS += -PIC ${OBJ_SET1} ${OBJ_SET2} : %.o : %.cc ${CCC} ${CCFLAGS} -m32 -o ${@} -c ${<} obj1.o : ${OBJ_SET1}