[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: debugging make variables using $(SHELL)
From: |
russ mok [Alumni] |
Subject: |
RE: debugging make variables using $(SHELL) |
Date: |
Tue, 28 Mar 2017 15:45:06 +0000 |
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.