Question is similar to this question
Handling header files dependencies with cmake
I have sample program dir having main.c main.h and CMakeLists.txt
main.h contents are
#ifndef MAIN_H
#define MAIN_H
int t=3;
int y=2;
#endif
main.c contents are
#include <main.h>
#include<stdio.h>
int main(){
printf("%d apple",t);
}
and CMakeLists.txt
PROJECT( test )
AUX_SOURCE_DIRECTORY(. test_SRCS)
include_directories(.)
ADD_EXECUTABLE (main ${test_SRCS})
but cmake is not rebuilding main.c on modification of header file.
I want it to auto-generate header file dependency.
Is it possible using cmake ?
if not is there any other tool which can do that ?
As mentioned in my comment, I have tried out your example and things were working fine: if main.h was modified then main.c would be recompiled.
My installation of CMake (version 2.8.0) told me to add
cmake_minimum_required(VERSION 2.8)
to the CMakeLists.txt file, but that is all of the adjustments I needed.
Answering this for others that google search...
I ran into this problem with one of my projects. As it turns out I added the header to the cpp file after running cmake. Re-running cmake fixed the problem. If you run into this, try that and see if it fixes the issue.
From the cmake 2.8.0 documentation of AUX_SOURCE_DIRECTORY:
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually
rerun CMake to generate a build system incorporating the new file.
Why do you want to avoid creating a list of files? Such lists generally do not change frequently.
Related
Maybe stupid question, but how do I change directory where cmake files gonna be created, so I can keep my project kinda cleaner.
For example when I run cmake -S. -B./src it is not gonna create files and directories like cmakeChache, cmakefiles and other in my source directory.
Btw I running linux.
I understood how to do it. I just had CMakeLists.txt file and my source c++ code in another directories and I don't know how to set source path to CMakeLists.txt file and c++ source in the same time so I just moved CMakeLists.txt file to source directory and now I don't have to set build path to path of my source code.
The syntax is:
cmake -S <PATH/TO/SOURCE_FILES> -B <PATH/TO/BUILD_OUTPUT>
cmake --build <PATH/TO/BUILD_OUTPUT> --target all
It is recommended that <PATH/TO/BUILD_OUTPUT> is not a sub directory of <PATH/TO/SOURCE_FILES>.
It should be parallel to the sources:
+-PATH
+-TO
+-BUILD_OUTPUT
+-otherstuff
+-SOURCE_FILES
Note: Most CMS(e.g. git) can be configured to not consider generated files.
I tried to add additional source file in FDK-AAC. But when I autoconf and configure for the compilation, my source file didn't get compiled. Any idea how to make autoconf to include my source file in compilation? Thank you.
Thank you everyone. For those who have the same problem as mine, the thing is there is the template Makefile.am which is used by automake. You just need to include your source file in the Makefile.am to get it compiled by generated Makefile.
Problem solved.
I'm using qmake to generate a Makefile. In my spec file, I override CXX and CC as such:
QMAKE_CC=/home/foo/gcc-4.7.2/bin/gcc
QMAKE_CXX=/home/foo/gcc-4.7.2/bin/g++
Now the generated Makefile uses those versions. However there is a variable called LINK in the generated makefile, which points to g++. Not /home/foo/gcc-4.7.2/bin/g++.
This causes my build to fail at the final step when compiling the executable from all the generated object files.
How do I get qmake to set LINK to /home/foo/gcc-4.7.2/bin/g++ in the generated Makefile?
Currently, I'm changing LINK by hand to get things to work.
You can override LINK in the same way:
QMAKE_LINK=/home/foo/gcc-4.7.2/bin/g++
I have been building a shared library with the Android NDK and now want to build it as a static library. I assumed that all I had to do was change BUILD_SHARED_LIBRARY to BUILD_STATIC_LIBRARY in Android.mk but now when I run ndk-build, absolutely nothing happens. It just comes right back to the command prompt without displaying anything. I tried ndk-build -n and it shows 3 rm commands being executed and nothing else. I tried ndk-build -B and it makes no difference. I tried ndk-build -d and there is nothing in the output related to my source files or the name of the library.
If I change the make file back to build the shared library, it compiles the source and links the .so with no problems.
Anyone have any ideas what could be wrong?
It seems that in order to build a static library, it must be a dependency of something. I was able to build my library as static by adding an Application.mk file with the following line:
APP_MODULES = mylib
In my project directory, i have:
./external/glew, which has glew compiled from source (ran make)
./external/glfw, which has glfw also compiled from source (ran make x11)
in my .c source code:
#include <stdio.h>
#include <stdlib.h>
#include "external/glew/include/GL/glew.h"
#include "external/glfw/include/GL/glfw.h"
i tried to compile using GCC:
gcc test1.c -o test1 -DGLEW_STATIC -L./external/glew/lib -lGLEW -lGLU -lGL \
-L./external/glfw/lib/x11 -lglfw
./external/glew/lib is where the libGLEW.a is and ./external/glfw/lib/x11 is where the libglfw.a is.
and it compiles without error. but then i try to run ./test1 it gives me:
./test1: error while loading shared libraries: libGLEW.so.1.6: cannot
open shared object file: No such file or directory
how do i compile glew & glfw statically?
EDIT 1 Thanks for the help guys. After some help from people in stackoverflow and old nabble I manage to write it down what needs to be done to statically linked GLFW and GLEW and put it on http://www.phacks.net/static-compile-glfw-and-glew/
Static libraries are not linked with -l… but just added to the linker source files. However please double check you really want to link those statically. The problem you have here is that the dynamic linker on *nix systems will by default only look into the system library directories and the path specified in the LD_LIBARY_PATH environment variable.
However it is possible to add relative linker paths to the executable, where libraries are located, too (--rpath linker option). That way you can ship the libraries in a directory relative to your executable, independently from the system libraries. If you do this, you also should look into binreloc