[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: debugging make variables using $(SHELL)
From: |
Duane Griffin |
Subject: |
Re: debugging make variables using $(SHELL) |
Date: |
Thu, 23 Mar 2017 10:14:02 +1300 |
Hi Russell,
On Wed, Mar 22, 2017 at 5:58 PM, russ mok [Alumni]
<address@hidden> wrote:
> My env relies heavily on recursive make, and my last rule is for debugging:
An interesting approach I hadn't considered, thanks! That would
certainly be much simpler than what we do.
Unfortunately it would not work for us: we build a number of
libraries, executables, and plugins that are inter-dependent in
various ways. Recursive make would not cut it, we rely on global
dependency analysis across our whole system.
To expand a bit more the basic outline of our build system is a
top-level framework that defines common rules, variables and sets of
templates (e.g. DEF_DLL that defines a shared library to be built). It
includes component modules that use the templates, e.g. $(eval $(call
DEF_DLL,LibraryName,$(SRCS),Lib1 Lib2...)) would define a shared
library "LibraryName" with dependencies on other previously defined
libraries "Lib1", "Lib2", etc. It defines rules and variables, e.g.
LibraryName_SRCS that contain the source files used to build it, etc.
Some of these are sometimes used in subsequent components' modules.
The shared library itself is also added to a global list of targets,
which is then used in the top-level framework to define what to
actually build. We make fairly extensive use of target-specific
variables, although I'd love to get rid of them: they are a frequent
source of subtle and nasty bugs.
Cheers,
Duane.
--
"I never could learn to drink that blood and call it wine" - Bob Dylan