magic/rules.mak

65 lines
2.3 KiB
Makefile
Raw Permalink Normal View History

# You shouldn't need to edit this file, see the defs.mak file
module: lib${MODULE}.o
depend: ${DEPEND_FILE}
# New Depend file generating line (Tim Edwards, 1/25/06). This gets around
# problems with gcc. The purpose of "make depend" is to generate a list of
# all local dependencies, but gcc insists that anything that is in, for
# example, the /usr/X11R6 path should also be included. The sed scripts
# (respectively) do: 1) remove comment lines generated by gcc, 2) remove
# any header (.h) files with an absolute path (beginning with "/"), and
# 3) remove isolated backslash-returns just to clean things up a bit.
rules.mak: fix module Depend and build rules The ../database/database.h dependency is already described (only when necessary) inside the Depend file for the specific complication unit. Not all objects are affected by database.h changes, so it doesn't need to be forced as a dependency for all OBJS. Depend itself was never rebuilt when a source file changed. This now happens, however technically the superior MAKE process needs to restart so it includes the new updated copy of Depend file we just updated. However in practice when developing, modifying #include directives does not happen often and doing 'make; make' will fix the issue performing an incremental build both times. So a minor caveat. Previously when a single source file was changed the entire module was recompiled, but we have a Depends file to manage the incremental build problem and we are not really using it (if we always recompile the entire module due to any one file change, there would be no need for Depends). Now when developing, a single *.c file change results in the Depends being rebuilt, then the single file compiled, then the module relinked. This is exactly the kind of incremental build speedup having a Depends file is designed to achieve. Additionally the use of a direct pipeline to create the file does not manage error scenarios. MAKE itself is driven by file existance and their timestamps for targets, so even if 'make depend' failed, it would still create an output file that MAKE can not distunguish between a well formed (possibly empty) Depend file and an incorrectly created partial. So building in a *.tmp file first and only if all the commands are successful then rename to target filename. This has the effect of making 'make depend' able to fail now.
2024-10-16 11:49:46 +02:00
# The $$PPID allows this to be run on the same dir in parallel without
# corrupting the output, the final MV is transactional. If that is needed
# it indicates a missing dependency somewhere in a upstream/parent Makefile.
${DEPEND_FILE}: ${DEPSRCS}
${CC} ${CFLAGS} ${CPPFLAGS} ${DFLAGS} ${DEPEND_FLAG} ${DEPSRCS} > ${DEPEND_FILE}$$PPID.tmp
${SED} -e "/#/D" -e "/ \//s/ \/.*\.h//" -e "/ \\\/D" -i ${DEPEND_FILE}$$PPID.tmp
${MV} -f ${DEPEND_FILE}$$PPID.tmp ${DEPEND_FILE}
# Original Depend file generating line:
# ${CC} ${CFLAGS} ${CPPFLAGS} ${DFLAGS} ${DEPEND_FLAG} ${SRCS} > ${DEPEND_FILE}
rules.mak: fix module Depend and build rules The ../database/database.h dependency is already described (only when necessary) inside the Depend file for the specific complication unit. Not all objects are affected by database.h changes, so it doesn't need to be forced as a dependency for all OBJS. Depend itself was never rebuilt when a source file changed. This now happens, however technically the superior MAKE process needs to restart so it includes the new updated copy of Depend file we just updated. However in practice when developing, modifying #include directives does not happen often and doing 'make; make' will fix the issue performing an incremental build both times. So a minor caveat. Previously when a single source file was changed the entire module was recompiled, but we have a Depends file to manage the incremental build problem and we are not really using it (if we always recompile the entire module due to any one file change, there would be no need for Depends). Now when developing, a single *.c file change results in the Depends being rebuilt, then the single file compiled, then the module relinked. This is exactly the kind of incremental build speedup having a Depends file is designed to achieve. Additionally the use of a direct pipeline to create the file does not manage error scenarios. MAKE itself is driven by file existance and their timestamps for targets, so even if 'make depend' failed, it would still create an output file that MAKE can not distunguish between a well formed (possibly empty) Depend file and an incorrectly created partial. So building in a *.tmp file first and only if all the commands are successful then rename to target filename. This has the effect of making 'make depend' able to fail now.
2024-10-16 11:49:46 +02:00
%.o: %.c
@echo --- compiling ${MODULE}/$*.o
${RM} $*.o
${CC} ${CFLAGS} ${CPPFLAGS} ${DFLAGS} -c $*.c
lib${MODULE}.o: ${OBJS}
@echo --- linking lib${MODULE}.o
${RM} lib${MODULE}.o
${LINK} ${OBJS} -o lib${MODULE}.o ${EXTERN_LIBS}
lib: lib${MODULE}.a
lib${MODULE}.a: ${OBJS} ${LIB_OBJS}
@echo --- archiving lib${MODULE}.a
${RM} lib${MODULE}.a
${AR} ${ARFLAGS} lib${MODULE}.a ${OBJS} ${LIB_OBJS}
${RANLIB} lib${MODULE}.a
${MODULE}: lib${MODULE}.o ${EXTRA_LIBS}
@echo --- building main ${MODULE}
${RM} ${MODULE}
${CC} ${CFLAGS} ${CPPFLAGS} ${DFLAGS} lib${MODULE}.o ${EXTRA_LIBS} -o ${MODULE} ${LIBS}
${DESTDIR}${BINDIR}/${MODULE}${EXEEXT}: ${MODULE}${EXEEXT}
${RM} ${DESTDIR}${BINDIR}/${MODULE}${EXEEXT}
${CP} ${MODULE}${EXEEXT} ${DESTDIR}${BINDIR}
.PHONY: clean
clean:
${RM} ${CLEANS}
tags: ${SRCS} ${LIB_SRCS}
ctags ${SRCS} ${LIB_SRCS}
# Depends are a somewhat optional part of the build process that are only useful when incremental
# building. If the file is here it's here, if not continue with build optimistically
ifneq (,$(wildcard ${DEPEND_FILE}))
include ${DEPEND_FILE}
endif