RE: debugging make variables using $(SHELL)

[russ mok [Alumni]]

Hi Duane

The technique of using $(SHELL) should work even without recursive make. You 
just don't need MAKE_LEVEL check. It gives me the 'final' snapshot of the 
definitions. You can try to activate it inside some of the rules and see if it 
is close to what your dump and reload scheme is offering you.

I wonder what you mean by inter-dependent? Is it circular dependency? My 
workaround to libA <--> libB is to merge them into one unit/component if simple 
code refactoring/restructuring cannot break it.

Because your problem this time is not as clear, I have to imagine/recall what 
it is like without recursive make.

Years ago, I did struggle with debugging make and it was not caused by 
recursive make but really I could no longer express what I needed using only 
the features in make (or the parts I was comfortable with).

It was hard using =/define/call/eval and seeing where these things get 
expanded. = doesn't work with cycle, but mixing it with := makes where I put := 
significant. I also didn't like counting the number of $ needed when using 
define/call...

In the end, I avoid using those hard-to-debug features with a solution based on 
submake/recursive make. I am not promoting submake/recursive make -- it was a 
logical choice for me because I do not need learning another tool. I suppose 
one can look at it as my way of doing custom 'configure'.

In particular, I wanted the full dependency by just specifying the immediate 
children. I still don't know how to do this with make, but I did achieve the 
desired effect using external topological sort.

Your problems could be completely different. I cannot tell for sure, but likely 
it is related to the use of = and how/where it gets expanded.

regards
Russell


________________________________________
From: Duane Griffin address@hidden
Sent: Thursday, March 23, 2017 5:14 AM
To: russ mok [Alumn
Cc: address@hidden
Subject: Re: debugging make variables using $(SHELL)

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
[http://mlm.polyu.edu.hk/PolyU80_Email_Signature.png]

www.polyu.edu.hk/80anniversary<http://www.polyu.edu.hk/80anniversary>

Disclaimer:

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose. If you are not the intended 
recipient, you should delete this message and notify the sender and The Hong 
Kong Polytechnic University (the University) immediately. Any disclosure, 
copying, or distribution of this message, or the taking of any action based on 
it, is strictly prohibited and may be unlawful.

The University specifically denies any responsibility for the accuracy or 
quality of information obtained through University E-mail Facilities. Any views 
and opinions expressed are only those of the author(s) and do not necessarily 
represent those of the University and the University accepts no liability 
whatsoever for any losses or damages incurred or caused to any party as a 
result of the use of such information.