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 [dua...@dghda.com] Sent: Thursday, March 23, 2017 5:14 AM To: russ mok [Alumn Cc: help-make@gnu.org Subject: Re: debugging make variables using $(SHELL) Hi Russell, On Wed, Mar 22, 2017 at 5:58 PM, russ mok [Alumni] <russ....@connect.polyu.hk> 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. _______________________________________________ Help-make mailing list Help-make@gnu.org https://lists.gnu.org/mailman/listinfo/help-make
