I am working on a system which is composed of many projects and makefiles. Each makefile includes .inc files from it`s dependencies. If a dependency is missing, it complains and tells the user to compile the dependency first. This part works ok. Problem is the clean target.
If a dependency is cleaned first and it`s inc file is deleted (since inc files include compile time options and hard paths, we prefer to delete them), then Makefile fails to load the .inc file and aborts. So the mechanism that makes sure we have the right dependencies, does not let us call the clean target -which does not require the dependencies-.
Is there any way to include or ignore .inc files according to the rule?
PS: Since we are already using "-" for error checking so that is not an option.
the canonical way to prevent including when cleaning is as follows:
ifneq ($(MAKECMDGOALS),clean)
include $(some .inc files)
endif
as described here https://www.gnu.org/software/make/manual/make.html#Goals
although if i understand correctly the errors you are experiencing are not because of the failed includes, which you are already supressing with -include, but because your makefile is dependent on some values from the includes.
to help you fix that we will need some code which demonstrates the problem. please read here for how to do so: https://stackoverflow.com/help/minimal-reproducible-example and http://www.sscce.org/
Related
I just took over a GCC project containing a makefile that has way to many include folders and source files listed. I started removing one by one and verified by compiling, but wondered, is there some way of looking at the compiled output (map files for instance?) and compare that to the makefile to clean out unnecessary files?
I'm not saying this will make any difference to the finished project, but I like to quickly look at the Makefile to see what this project involves. Now it looks like it involves "everything"
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.)
This question already has an answer here:
how to make clean without any modification?
(1 answer)
Closed 3 years ago.
I have a very complicated makefile which I am not going to include here for obvious reasons. I have rules to build dependency files and then include them with lines along the lines of '-include myobj.d'.
I also (obviously) have a rule to build a *.d file.
I then have rules along the lines of
.PHONY: clean
clean:
rm myobj.d myobj.o ...
When I do make clean, first it rebuilds all the .d files before deleting them. I ran make with -d and examined the debug information and it is trying to rebuild all the files I include with "-include" before examining the targets it was told to build. I have a whole pile of "rules.mk" for building different code units and it tries to rebuild all of those too.
This wouldn't be a problem, except that the .d files that are being included actually do have rules to build them. When I say "make clean" I want make to just execute the clean rule, not rebuild all the stupid dependency files just so I can delete them...
This is particularly problematic if the build is in a weird state where half the code is built and the rest isn't and I am trying to do a make clean to get back to a good state.
How do I tell make to not try to automatically rebuild an included file?
You do not need rules for .d files these days, this is a common misconception. See Automatic header dependencies with gmake for more details.
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 develop C/C++ using the Eclipse IDE. Eclipse also generates a makefile which I don't want to edit as it will simply be overwritten.
I want to use that makefile for nightly build within Hudson.
How do I pass #defines which are made in the project file of the IDE to the makefile ? (and why doesn't Eclipse already include them in the generated makefile?)
I actually had this figured out once, then accidentally overwrote it :-( But at least I know that it can be done...
If you are running make from the command line, use
make CPPFLAGS=-DFOO
which will add -DFOO to all compilations. See also CFLAGS, CXXFLAGS, LDFLAGS in the make manual.
You could write a small program to include the headers and write a makefile fragment which you include in the main makefile (requires GNU make).
This is a fairly ugly solution that requires a fair amount of hand hackery. More elegant would be to parse the project file and write the makefile fragment.
For GCC use -D define.
OP commented below that he wants to pass the define into make and have it pass it on to GCC.
Make does not allow this. Typically you just add another make rule to add defines. For instance 'make release' vs 'make debug'. As the makefile creator you make the two rules and have the defines right in the make file. Now if Eclipse is not putting the defines into the makefile for you, I would say Eclipse is broken.
If you're using autotools another options is to have 2 directories 'bin/debug' and 'bin/release'.
# Simple bootstrap script.
# Remove previously generated filed and call autoreconf.
# At the end configure 2 separate builds.
echo "Setting up Debug configuration: bin/debug"
../../configure CXXFLAGS="-g3 -O0 -DDEBUG=1"
echo "Setting up Release configuration: bin/release"
cd bin/release/
../../configure CXXFLAGS="-O2"
Setup Eclipse. Open the project's properties (Project->Properties->C/C++ Build->Builder Settings) and set the Build Location->Build Directory to
${workspace_loc:/helloworld/bin/debug}
Replacing 'helloworld' with your project's directory relative to the workspace (or you can supply an absolute path ${/abs/path/debug}). Do the same thing with the Release config, replacing "/debug" with "release" at the end of the path.
This method seems like a waste of disk space, but a valid alternative to achieve completely separate builds.