I'm building the boost libraries with bjam for both the intel compiler and vs2008, and I can't tell what optimizations are being passed to the compiler from bjam. For one of the compiler's gcc, I can see some optimizations in one of the bjam files, but I can't find the optimization flags for the compilers I care about. So, my questions are -
Does anyone know where the default optimization flags are located?
If they're declared within bjam, does anyone know how I can override them?
If you are interested in looking at the entire set of options that are passed to invoke the compiler when building you can run bjam with the -n -a options and the rest of the building options to give you the complete set of commands invoked, and any response files generated (see Boost Jam Options). Also you can look at the Boost Build sources directly and see what the specified features are translated into (see Boost Build Tools Files). For example:
For GCC see gcc.jam
For MSVC see msvc.jam
You can likely figure out the same for other compilers by just looking through the sources as they are fairly self explanatory. And you can just search for "<optimization>" and "<inlining>" in the *.jam sources.
You can override them in the command line by specifying the feature=value option in the command line when building. The options match the <feature>value specifications you see in the toolset files. For example, to override the optimizations feature you would specify in the command line some like "optimization=speed". If you want more fine grained control you would have to delve into Boost Build specifications and likely have to create a variant of your own to define specific options and features to build with.
Related
I noticed that the recent version of CMake release notes has a line about a new feature:
Makefile Generators, for some toolchains, now use the compiler to extract implicit dependencies while compiling source files.
This sounds like a cool feature, but I couldn't figure out how to actually use it. A quick search didn't return any obvious documentation. Does anyone here know more about how to use it?
This is referring to implicit header dependencies. GCC, Clang, and several other compilers have a flag for writing files listing these dependencies during the first compile. CMake then points the generated build systems to these files so they can load the extra dependencies during incremental builds.
This is all automatic with CMake and requires no special action on your part. It can, however be disabled by setting a special variable to FALSE, CMAKE_DEPENDS_USE_COMPILER.
Here is the merge request that introduced this feature: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5528
For further reading, see the documentation for the -MMD flag on GCC: https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
I am trying to report a bug for a project using Bazel. As part of the issue report I would like to include information about the used C++ compiler.
Which command can I use to do so?
bazel build -s //the_target shows me that external/local_config_cc/wrapped_clang seems to be the compiler. In bazel-<project>/... I can find that path, but running the executable wrapped_clang in there, just leads to an abort.
This answer only applies if you're using Bazel autoconfigured C++ toolchain. If you don't you'll have to modify it.
So for debugging the best would be to zip entire local_config_cc and also to provide version of the compiler ($CC --version). You get the local_config_cc at:
`bazel info output_base`/external/local_config_cc
Path to the compiler is written into the wrapped_clang script in case of the toolchain that supports both C++ and ObjC (this one gets enabled when Xcode is properly detected). C++ only toolchain invokes compiler directly (but the CROSSTOOL file can still be useful for debugging). And just in case, you can force C++ only toolchain by setting BAZEL_USE_CPP_ONLY_TOOLCHAIN=1 environment variable.
Several static analysis tools designed for C/C++ exist, but they are not particularly useful for testing CUDA sources.
Since clang version 6 is able to compile CUDA, I wanted to check what are my options with using clang-tidy, which does not seem to have option for switching architectures.
Is there a way to make it work? For example compile time switch for turning on CUDA parser, extension in form of custom check, or is it maybe planned feature?
One of the problem with the clang-based tools is that they are not parsing the files in exactly the same way as clang does.
The first problem is that unlike C/C++ compilation, CUDA compilation compiles the source multiple times. By default clang creates multiple compilation jobs when you give it a CUDA file and that trips many tools that expect only one compilation. In order to work that around you need to pass --cuda-host-only option to clang-tidy.
You may also need to pass --cuda-path=/path/to/your/CUDA/install/root so clang can find CUDA headers.
Another problem you may run into would be related to include paths. Clang-derived tools do not have the same default include paths that clang itself uses and that occasionally causes weird problems. At the very least clang-tidy needs to find __clang_cuda_runtime_wrapper.h which is installed along with clang. If you run clang-tidy your-file.c -- -v it will print clang's arguments and include search paths it uses. Compare that to what clang -x c /dev/null -fsyntax-only -vprints. You may need to give clang-tidy extra include paths to match those used by clang itself. Note that you should not explicitly add the path to the CUDA includes here. It will be added in the right place automatically by --cuda-path=....
Once you have it all in place, clang-tidy should work on CUDA files.
Something like this:
clang-tidy your-file.cu -- --cuda-host-only --cuda-path=... -isystem /clang/includes -isystem /extra/system/includes
I am building an open source project (kst, v2.0.8) that uses CMake. I am using CMake v2.8.12.2 and MSVC 2008 as a compiler and am generating NMake makefiles to build it on the command line. I can get it to build successfully with this setup. These versions are mandated so I cannot currently use a later version of CMake or MSVC.
I need to be able to perform a source code analysis of kst using HP's Fortify and to be able to use it from the command line it works in one of two ways:
Touchless mode where it creates it's own "cl.exe", sets the path to it before the path to the real cl.exe and therefore gets launched during build.
Set the compiler in the makefile to the Fortify command line, e.g. sourceanalyzer -b build_id cl instead of cl.
Either way I need to force the compiler that cmake generates into its makefiles to be something that cmake does not automatically detect.
I've tried setting the compiler when running cmake following the same method in this question but cmake still insists on putting the full path to the MSVC cl.exe in the makefiles.
cmake -DCMAKE_C_COMPILER=cl -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER=cl -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I also tried setting the compiler to invoke Fortify but when cmake tests the compiler it fails saying that it cannot find the compiler. (I have also tried this without the FORCED=ON arguments and in that case it says the compiler fails.)
cmake -DCMAKE_C_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_C_COMPILER_FORCED=ON -DCMAKE_CXX_COMPILER="sourceanalyzer -b %BUILDID% cl" -DCMAKE_CXX_COMPILER_FORCED=ON -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=%CFITSIO_DIR% -G"NMake Makefiles" ..\cfit3250
I could probably search and replace all the compiler invocations in the makefiles but I'd have to remember to do that after every cmake, and it would be tedious seeing as there are multiple projects / makefiles / calls to cl (rather than defining a CC variable in the makefile). I'd rather have a way to make cmake use the desired compiler right from the offset.
UPDATED: Testing showed the original suggested approach didn't work as expected on at least some platforms. It seems using a wrapper script is likely the way to go.
If you really want to force a particular compiler and by-pass CMake's compiler checks, the CMakeForceCompiler module may be what you are looking for. That link to the CMake docs contains a trivial toolchain file example which shows how to use a specific compiler invoked as a simple command with no path. Unfortunately, CMake still converts this to an absolute path, so on its own, this won't solve your problem. You could, however, use a toolchain file to point at a wrapper script and use CMakeForceCompiler to bypass the compiler checks. This combination should yield the behaviour you've asked for, but note that CMakeForceCompiler is now deprecated.
Note that when using the CMakeForceCompiler module, you take on a bit more responsibility for telling CMake information, notably the compiler ID of the particular compiler you want to force using, but from the CMake docs it seems pretty clear this will just be MSVC in your case.
To use a toolchain file, invoke CMake with a -DCMAKE_TOOLCHAIN_FILE=path/to/file option pointing at your own custom toolchain file. The CMake docs have a specific section covering the use of toolchains, although it does gloss over some of the important nitty gritty details.
As mentioned in #Tsyvarev's comment, the use of a wrapper script is likely to be your best way of dealing with this. That wrapper script just needs to forward the call to the usual compiler command without specifying a path. You then take responsibility for ensuring the command will be on your PATH when you do a build. Something as simple as the following should suffice as a wrapper batch file on Windows (untested):
cl %*
Now, you can control whether the Visual Studio compiler or Fortify gets invoked purely by the PATH the build sees. Personally, I think this is a bit fragile, but it's what you asked for. ;)
As a more robust alternative, is it possible to use two completely separate builds? If so, then I'd recommend that as a better alternative. Build one with the default Visual Studio compiler as normal and for the other build, use a toolchain file to point at the Fortify compiler to get CMake to bypass its compiler checks. That way you aren't relying on the build environment being set up a particular way.
I'm adding a SYCL/OpenCL kernel to a parallel C++ program which is built with cmake. Using SYCL means I need to get cmake to compile my C++ source file twice: once with the SYCL compiler, and once with the project's default compiler, which is GCC. Both compilations produce outputs which need to be included when linking.
I'm completely new to cmake. I've added the GCC compile and link steps to the project's CMakeLists.txt, but what's the best way to add the SYCL compile step? I'm currently trying the "add_custom_command" option with "PRE_BUILD", but the command which is run doesn't seem to know about the paths which are provided to the normal compile and link steps: the current working directory, include directories, source directories, etc. I'm having to specify all of these manually, and I'm having to figure some of them out first.
It feels like I'm doing this the hard way. Is there a recommended (or at least better) way to get cmake to compile a file twice with two different compilers?
Also, there used to be a SYCL tag, but it's disappeared. Can someone recreate it, please?
Be aware that PRE_BUILD only works as PRE_BUILD in Visual Studio 7, for other targets is just PRE_LINK.
If you need to use two compilers on the same source file, just add a dependency from the GCC compile and link to the custom target you are using, so the GCC is executed after the SYCL compiler.
I can think of a couple other ways to do it.
Generate two build configurations
Write a script to call both compilers
The first method is probably the easiest. You might need to maintain two seperate CMakeLists.txt files, or possibly just parameterize the compiler and options and pass them arguments to Cmake when you generate (CC=gcc, CXX=g++, CFLAGS/CXXFLAGS, etc...). You might be able to do the same with the underlying build system (e.g. make) and just run it twice.
The second method is a bit more complicated. Write a simple script that accepts both sets of compiler options and compile each file using the compilers in sequence. Then the script could be then configured as CC/CXX.
So, the command options would look something like this...
--cc1 sycl --cc2 gcc --cc1opts ... --cc2opts ...
I'm not familiar with SYCL though, so I don't know how it's normally used.