A small change in a 1000's of lines of code leads to running the ./configure again on the entire software.
Is there any alternative, where we can compile only the changed file and the files associated with it?
If you have a sane Makefile.am with proper dependencies, running ./configure and make should only recompile files that depend on the touched file. So make already does what you are asking for.
If your Makefiles are not sane (e.g. they only work if you run make clean) and you are compiling C or C++ sources, using ccache might give you a speed gain. With ccache only the preprocessor part is run and its output compared to a cache of compile outputs. If nothing changed in the file or its includes it won't be recompiled. Properly installed it is run in a transparent way.
Related
After an error occurred because of a missing flag or incorrectly set environment variable, is it possible to continue compiling once the mistake has been fixed?
I regularly use CMake and make to compile toolkits that take quite a while to compile and, also regularly, I accidentally set variables incorrectly in the process. Just now for example, I was attempting to include OpenInventor headers which on my machine are located in the directory /Users/user/software/prod/coin/include/Inventor.
I mistakenly passed
-DINVENTOR_INCLUDE_DIR=/Users/user/software/prod/coin/include/Inventor
rather than the correct
-DINVENTOR_INCLUDE_DIR=/Users/user/software/prod/coin/include
This only became an issue after 30 minutes when about 95% of the compilation was completed. Because I knew that reconfiguring using CMake would force a recompilation from scratch, I tried to add -I/Users/user/software/prod/coin/include to CMAKE_CXX_FLAGS in CMakeCache.txt but to no avail–it still recompiled from scratch. Since only a single source file actually includes the headers in question, it would be desirable if I could start compiling from the point where it exited with an error once the relevant path has been corrected. How can I do this and, as an aside, why does it force the compiler to start from scratch?
I'm using CMake version 3.11.1 and clang (Apple LLVM version 9.1.0) on macOS 10.13
CMake does not need to recompile everything just because it regenerates its makefiles. It will still perform normal make avoidance operations. However CMake does track the compiler options used to build each target, so if you make a change in the compiler options for all the targets then they'll all need to be rebuilt.
If this compiler option is only needed for one target, you can add it to just that target an no others, with something like this:
set_property(SOURCE my_source.c APPEND PROPERTY
COMPILE_FLAGS -I/foo/bar)
then it should only rebuild that one source file.
CMake looks for files' "last modified" times to decide which files need recompilation. But if you change the input to CMake itself, then it needs to regenerate the Makefiles and therefore recompile everything. But still, one hack may be possible...
CMake stores information about the include directories and the libraries to be linked in various text files in the build directory. So one hack (not recommended, but works) can be to modify these text files.
In the particular example that you mentioned, the hack would be to search and replace all occurrences of /Users/user/software/prod/coin/include/Inventor with /Users/user/software/prod/coin/include in all the files of the build directory.
(As an aside, if you don't already know, you can use make -j <n> to build using multiple threads which can considerably decrease the build times.)
Using cmake 3.7.2 I recently switched a project from Unix Makefile to Cmake with Unix makefile generator.
All works as expected and the main problems we wanted to solve are solved (command line length in windows).
I discovered a great thing that is dependency checking as there is no more need to clean in normal situations and rebuild unneeded files.
Now the dependency is very slow (about 70s) when the all build is only 20s. Is there a way to speed up the checking ? Or to find the bottleneck of this check ?
GNU make dependency check IS slow.
Ninja was designed to be much faster ans IS definitely faster.
The update to Ninja is very simple as only cmake generator (-G) has to be modified.
I have a big project which after make ends up with 1GB of executables and libs.
I use standard workflow: autogen, configure, make, make install. The problem is after this all the files ends up in default system directories along with other installed software and I can't selectively use strip to reduce the size of the project's executable and libraries. What is a proper workflow to strip symbols after make is done? Are there options for this in configure other then visiting each source directory and do it on my own after make is over?
I am currently working on a project on a student job and writing some code. Whenever I want to compile my file, my supervisor told me to first do gmake clean and then do gmake. Otherwise,some errors from previous gmake may not be solved in the fresh gmake.
My project has a lot of unnecessary files that I am not editing but since i gmake clean everytime, the compiler compiles them again everytime which takes a lot of time.
So, if I am not changing the other files, then I don't need to recompile them and the only file that I change is always recompiled simply with gmake, right? So why should I gmake clean everytime?
Is my supervisor just telling me a good programming practice or am I missing some important concept of gmake clean?
The difference between gmake and gmake clean is that the former builds the default target while the latter "builds" the specific target clean, which usually consists of clean-up instructions to remove files that were created during the build process (object files, temporary files, generated code, …). gmake clean should restore the source tree to a clean state. However, if it actually succeeds depends on how the source tree looks like and what instructions the target contains.
definitely not a best practice... this is usually the quick and dirty solution when the makefile contains a few mistakes and the dependencies are not ok
do gmake clean before gmake in case you have difficulties to compile. just to check if the problem does not come from an old compiled file.
otherise do only gmake in orther to compile your newest changed files.
you superior gived you an advice to handle difficult and strange compilation behavior.
I'm trying to build a cross-compiler (x86->64) on my windows system, with the aim of targetting windows 64, however my software currently relies on open source libraries which also have open source dependencies for which there are no prebuilt binaries available with which I can compile. This means that if I want the 64 bit versions I need to compile them.
I've installed MSYS and mingw, I'm also in the process of adding mingw-w64 to the mix so that I can finally compile the libraries in 64 bit form for use with my software. I'm following the steps as closely as I can using these instructions and in the order listed on that page, I'm currently at the step titled "Building the GCC core cross-compiler(s)", but when I try to compile with the line:
$ ../gcc-4.6.1/configure --target=x86_64-w64-mingw32 --enable-targets=all && make -j 6 all-gcc && make -j 6 install-gcc
I get the output pasted here. I should note that I of course snipped the previously executed commands and that last command was the last one listed before all the errors were displayed. Also, I have no idea if it's the cause of all the errors due to the '-j 6' argument, but everything prior to it at least looked successful.
What's the problem and how can I fix it?
Oh, in anticipation of one potential suggestion; no I can't just switch to cygwin.
Edit: Okay after executing them individually, here's the output of the configure command, the output produced by make all-gcc (no -j argument), and config.log. Note, I didn't run a make clean beforehand which may explain the different ending, I didn't do it in the interest of time to write this update, but I suppose I'll just make a different compile folder and re-execute it cleanly to hopefully see the same error as before while I wait for a response.
Edit 2: The make all-gcc failed again as expected, this time the output should help a little more I hope.
Thanks very much for your help.
Your config.log shows that the build process will use the binaries in x86_64-w64-mingw32/bin for stuff like ar, as etc... These are for internal compiler use only, and they should all be available in your /mingw/bin directory. I would strongly suggest asking on the mingw-w64-public mailing list for help.