I am modifying a CMakeLists.txt file for a fortran code. I need to add a directory that contains a precompiled module.
How can I do that in CMakeLists.txt ?
There is a target property called Fortran_MODULE_DIRECTORY
For good measure, I also add the module directory as an include directory. gfortran looks for .mod files in the include directories.
set_target_properties( Target PROPERTIES Fortran_MODULE_DIRECTORY "dir" )
target_include_directories(Target PUBLIC "dir" )
Edit
Reading through your question again, I see that the module you are interested in is already compiled. Fortran_MODULE_DIRECTORY specifies where to PUT .mod files, and adds that directory as a place to look for them. target_include_directories statement just specifies where to look for them. I am most familiar with using gfortran, which has this in it's man page:
-Idir
These affect interpretation of the "INCLUDE" directive (as well as of the "#include" directive of the
cpp preprocessor).
Also note that the general behavior of -I and "INCLUDE" is pretty much the same as of -I with
"#include" in the cpp preprocessor, with regard to looking for header.gcc files and other such things.
This path is also used to search for .mod files when previously compiled modules are required by a
"USE" statement.
-Jdir
This option specifies where to put .mod files for compiled modules. It is also added to the list of
directories to searched by an "USE" statement.
The default is the current directory.
This is what CMake will do for you and your compiler; you shouldn't need to specify these flags explicitly. In your case, just the includes should be sufficient, since the module has already been compiled.
However, if you find it's not working with your compiler, you may have to specify them manually by setting the variable CMAKE_Fortran_FLAGS.
Hope this helps.
Related
I hope this is a simple question and I'm just missing something fundamental.
I'm trying to emulate a binary build manager for an embedded Cortex-M0 target using a CMake project. I'm having some trouble figuring out how to generate list files for each dependency of my executable target.
The current build system, when building a file called main.c passes -Wa,-alh=.\CortexM0\ARM_GCC_493\Debug/main.lst as an argument to gcc. I can't figure out how to get CMake to use the current filename without the extension to save the file.
I've looked at the get_filename_component command, but it appears only to get the filename of the output:
add_executable(TestExe main.c)
get_filename_component(curr_name TestExe NAME_WM)
message(${curr_name})
As expected, this prints TestExe instead of the hoped for main
Is there a simple variable I'm overlooking that I could put in my toolchain file's CMAKE_C_FLAGS like -Wa,-alh=${CURR_SOURCE}.lst? Or some other method that I'm not seeing?
System info:
Windows 10
Msys shell
CMake 3.7.2
arm-none-eabi-gcc v4.9.3
You can use Expansion Rules and extend CMAKE_C_COMPILE_OBJECT:
set(CMAKE_C_COMPILE_OBJECT "${CMAKE_C_COMPILE_OBJECT} -Wa,-alh=<OBJECT>.lst")
But there is unfortunately
no Expansion Rule that does give the current source file without path and extension
so you will get in the above example main.c.o.lst as an output name
Footnote: In CMake generated makefile projects, if you just need the assembly file can just do make main.s or for the pre-processed file make main.i.
I am trying to use gurobi in OMNet++. I have included gurobi_c++.h and in order to detect this file, I have already told the compiler where it can find it and the libraries. To do so, I went to Makemake options, custom, Makefrag and added two lines: EXTRA_OBJS += -LC:/gurobi701/win32/lib and CFLAGS += -IC:/gurobi701/win32/include. The first contains the path to gurobi C++ libraries and second contains the path to header file gurobi_c++.h. I also added the path to the include file in the Includes section in Path and symbols part for GNU C++ and path to libraries to Library Paths.
Despite all these, when I compile it says undefined reference to error for all functions used from gurobi_c++.h. I can see that it detects gurobi_c++.h, but I still have those errors.
Any ideas on what may cause the problem?
contents of bin folder:
contents of lib folder:
You need to link with gurobi_c++ library file. Change EXTRA_OBJS into:
EXTRA_OBJS += -LC:/gurobi701/win32/lib -lgurobi_c++
assuming that the library is called libgurobi_c++.a or libgurobi_c++.dll.
This question isn't specifically related to cross-compiling but has arisen as I have a problem related to architecture specific headers while trying to cross-compile a library.
I am trying to cross-compile OpenCV, the target is an ARM processor and I am compiling on an x86_64 processor. The build fails because a header file cannot be located:
/usr/include/zlib.h:34:19: fatal error: zconf.h: No
such file or directory #include "zconf.h"
Sure enough in zlib.h there is a reference to zconf.h:
#include "zconf.h"
However when I look under <path_to_arm_filesys>/usr/include I actually find zconf.h under <path_to_arm_filesys>/usr/include/arm-linux-gnueabihf directory. So as I understand it the C preprocessor won't find zconf.h as the reference to it does not include the reference to the architecture-specific sub-directory.
To try and understand how zconf.h is actually found, I referred to the host machine and where zconf.h is located. Similarly, it is located under /usr/include but under the architecture-specific x86_64-linux-gnu directory.
So if in the source code the is no specific reference to architecture (as to be expected) in any #include how does the (GNU) C pre-processor know where to look? Is it a case that the pre-processor already knows its architecture-target and can automatically append another architecture specific directory to all the include directories it knows about? Or must I specifically inform it with the use of the -I flag of these specific directories?
There are 3 ways to say the compiler where to find headers :
set the --sysroot option #preferred for cross-compilation
-sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler normally searches for headers
in /usr/include and libraries in /usr/lib, it instead searches
dir/usr/include and dir/usr/lib.
In this case you must have all libraries and headers under the sysroot folder.
Directly say with -I options where to find the headers.
Set the C_INCLUDE_PATH/ CPLUS_INCLUDE_PATH env variables
For #include preprocessor will seachy in search system directories and directories that were provided by compiler.
For #include "filename" preprocessor will search in the same folder where you have file that have this include.
https://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html
https://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html
Automake 1.14 is causing us a few issues. At first, automake errored with the complaint:
warning: source file 'X' is in a subdirectory but option 'subdir-objects' is disabled
So I enabled subdir-objects, but now it isn't recompiling some files. For example, lets say
src/a/foo.c is compiled in SUBDIR a but in src/b, I would like to compile it again with different preprocessor flags, however since ../a/foo.o already exists, make doesn't rebuild it. This is because subdir-objects changes am_b_OBJECTS to look for ../a/foo.o instead of foo.o. Is there a way I can get around the original complaint and instruct make to build the file a second time with the appropriate preprocessor flags? This all worked on previous versions of automake.
I would settle for executing rm ../a/foo.o before compiling src/b but I don't know how to edit the Makefile.am to make that happen.
This happens if you're using subdir-objects under the same tree from different Makefile.am files. As automake can't see you're using the same source file with different parameters it'll assume it was rebuilt correctly.
The proper solution to this is to not use separate Makefile.am files and instead rephrase the build system as non-recursive automake and so in that case it would then build foo.c as foo-a.o and foo-b.o.
I have a CMakeLists.txt that specifies multiple executables. For only one of these projects, I'm wanting to use the Static Runtime.
I found this solution here: Setting the MSVC runtime in CMake
This involves changed the CMAKE_CXX_FLAGS and CMAKE_C_FLAGS (as well as others).
However, doing something like this will change the runtime library for every project. With my testing, doesn't matter where you set these, it changes it for everything.
Is there any way to do this for just one project?
You'd be able to do this if you give your "Static Runtime" executable its own CMakeLists.txt file and include it from the parent one via add_subdirectory.
Variables set in the subdirectory CMakeLists.txt don't affect similar ones in the parent scope, so you can have the /MD or /MDd flags in the parent CMAKE_<LANG>_FLAGS_<BUILD>, and replace these with /MT or /MTd in the subdirectory.
Note that even though the command is called add_subdirectory, it need not refer to an actual subdirectory in the filesystem sense - just some other directory with its own CMakeLists.txt.