[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: debugging make variables using $(SHELL)

From: Sébastien Hinderer
Subject: Re: debugging make variables using $(SHELL)
Date: Thu, 23 Mar 2017 08:54:21 +0100


Duane Griffin (2017/03/23 10:14 +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.

I don't think so. If "recursive make" means that make calls itself
recursively, then my understanding is that this approach is really not
so good, see e.g. the "Recursive Make Considered Harmful" article which
I guess is well known here.

> 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.

Which is a much better way because one single instance of make has
access to the whole dependency graph, meaning among other things that
make -j will be as parallel as possible.

> 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.

Doing exactly the same here, in the process of migrating from the
recursive makefiles approach to the one you describe.

> 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.

Thanks for emphasizing this!


reply via email to

[Prev in Thread] Current Thread [Next in Thread]