gnu-make

Make chooses the same source file for different object files. Both are a list of files, only with different filenames. Make switches between the object files but not the source files. I've already tried some of the answers on StackOverflow with related problems, though those solutions either seem too complicated for what's needed, some don't work and others need the files to be in one directory. I've also tried compiling the files together in one go (with gcc), but this gives some problems with the linking of the rest of the file. $(OBJFILES): $(SRCFILES) $(CC) $(CCFLAGS) -c $< -o $@ $

This is my absolute first time ever making a makefile, and I'm really trying to understand the process. I'm trying to create a very simple makefile for a C++ project whose structure is as follows: root folder makefile readme src folder ...source files all here... include folder ...header files for external libraries here... lib folder ...external lib files all here... bin folder ...output directory for built executable... obj folder ...object files all here... I followed the tutorial here . Here's my makefile: IDIR=include . CC=g++ CFLAGS=-I$(IDIR) ODIR=bin/obj LDIR=lib LIBS=none SRC=src _DEPS

I am trying to build glibc 2.27 on Clear Linux, obtained here: https://www.gnu.org/software/libc/sources.html According to the help, I should build into a directory outside of the source folder using the prefix command. As far as I can tell, I am doing what is described in the installation help: Configuring and compiling the GNU C Library The GNU C Library cannot be compiled in the source directory. You must build it in a separate build directory. For example, if you have unpacked the GNU C Library sources in '/src/gnu/glibc-VERSION', create a directory '/src/gnu/glibc-build' to put the object

I'm compiling LLVM as well as clang. I noticed that the output of compilation has llvm[1]: or llvm[2]: or llvm[3] : prefixed to each line. What do those integers in brackets mean? It's the number of the compilation job ( make -j ). Helpful to trace compilation errors. Apparently, it's not connected to the number of the compilation job (can be easily checked via make -j 1). The autoconf-based build system indicates the "level" of the makefile inside the source tree). To be prices, it's a value of make's MAKELEVEL variable. The currently accepted answer is not correct. Furthermore, this is

I have another make -like tool that produces an XML as an artifact after parsing my makefile which I'll then further process with Python. It'd simplify things for me - a lot - if I could have make consider every single prerequisite to be an actual target because then this other tool will classify each and every file as a "job". This is a fragment of my makefile: .obj/eventlookupmodel.o: C:/Users/User1/Desktop/A/PROJ/src/AL2HMIBridge/LookupModels/eventlookupmodel.cpp C:\Users\User1\Desktop\A\PROJ\src\AL2HMIBridge\LookupModels\eventlookupmodel.h \ C:/Users/User1/Desktop/A/PROJ/qt5binaries

I'm trying to create a generic build template for my Makefiles, kind of like they discuss in the eval documentation . I've run into a known bug with GNU Make 3.80. When $(eval) evaluates a line that is over 193 characters, Make crashes with a "Virtual Memory Exhausted" error. The code I have that causes the issue looks like this. SRC_DIR = ./src/ PROG_NAME = test define PROGRAM_template $(1)_SRC_DIR = $$(SRC_DIR)$(1)/ $(1)_SRC_FILES = $$(wildcard $$($(1)_SRC_DIR)*.c) $(1)_OBJ_FILES = $$($(1)_SRC_FILES):.c=.o) $$($(1)_OBJ_FILES) : $$($(1)_SRC_FILES) # This is the problem line endef $(eval $

Typical makefiles often use the built-in variables CFLAGS , CXXFLAGS , CPPFLAGS and so on 1 to set the flags passed to the C, C++ or other compilers/tools. In principle, this sometimes even lets you avoid writing a compilation recipe entirely since the various built-in rules use these flags. In general, a makefile might add things to the FLAGS variables that are required for the code to compile, such as include directories, arguments indicating which language standard to use and so on. The variables might also include "optional" or "default" arguments, such as optimization level, warning level