Re: [PATCH v2 1/6] * expand.c (variable_name_extract): extract variable name and strip prefix.

[Tim Murphy]

This sounds like an extremely useful debugging feature.   I have often
had the problem of getting the wrong build parameters but not being
sure exactly why because of the great complexity of makefiles that are
trying to build many different sorts of object files all with slight
variations that are based on lots of configuration options.

In the end one has to pepper the makefile with $(info) statements to
find out and this can be impossible when dealing with a customer.

I think the commandline option might not be appropriate and the
feature should absolutely not be active or use memory unless the
commandline option is on.

As for whether the implementation is correct or optimal or fits make
standards or whether it should really be part of the core gnumake
(instead of being some sort of frequently updated patch/fork) I don't
know.

Regards,

Tim

On 21 August 2014 08:25, Macpaul Lin <address@hidden> wrote:
> Hi, Paul and other developers,
>
> 2014-08-18 22:35 GMT+08:00 Paul Smith <address@hidden>:
>> On Mon, 2014-08-18 at 21:27 +0800, Macpaul Lin wrote:
>>> Variables used in conditional lines usually has '$',
>>> '(', and ')' prefix, and etc.
>>> We can use vairable_name_extract() to extract pure variable
>>> name without these prefix.
>>
>> Hello.  Thanks for your work on GNU make!
>>
>> Can you provide some sort of summary of the feature you've created, what
>> its goals are, examples, etc.?
>>
>> It can be helpful to contact me or someone on the development team
>> before (or while) doing feature work for GNU make.  As a GNU project,
>> for example, we'll need to get copyright assignment paperwork for any
>> contribution of significant size and this takes some time.
>>
>> Also, we may have suggestions or alternative implementations or concerns
>> that should be considered.  Of course these can always be addressed
>> later, but it can save some effort to think about them up-front.
>>
>> And finally, note that fully-formed changes need to have at least a stab
>> at changes to the manual (I usually rework these but it's helpful to
>> have a starting point) and some additions to the regression test suite,
>> if possible.
>>
>> Cheers!
>>
>
> It's very happy to receive your response!
> Any kind of paperwork of copyright assigment is okay!
> Sure, alternative implementations or any other concenrs need to be discussed.
> GNU tools are widely delopyed and used in every single second.
> I hope the patches could help people instead of bring them disasters.
>
> About the paperwork, because I'm living oudside of U.S. If it can be done by
> email or fax is good. If postmail is necessary will be okay, too. Just take
> longer round trip time of these documentations.
>
> The following is the description of the purpose of these patches.
>
> * expand.c (variable_name_extract): extract variable name and strip prefix.
> * variable.h: Add support of struct value_records and parent_records
> * variable.c: Add support for constructing value_records and parent_records
> * read.c: Construct the dependency chain between parent and target variable
> * load.c: add support of parent_records
> * main.c: add --dep parameter for print variable dependency
>
> This set of patches were created to help developers to understand
> the dependencies between compile options or any other variables defined
> in makefiles.
> The dependencies especially indicate the relationship between a variable
> parent (assigner) and a variable itself as a child (assignee).
> The relationship between variable parent and variable child usually defined
> by conditional lines (ifeq/ifneq/ifdef/ifndef).
>
> By recording the operation history of these conditional lines, we can keep
> the operation history of a variable child and its variable parents.
> These operation histories are stored in value_record and parent_records.
> A value_record is a linking list to record each value was assigned to a
> variable caused by a conditional line. And the parent_record will keep the
> variables which made the value is assigned to this child value.
>
> Developers can simply dump all these informations by simply use command line
> `make --dep` to dump the dependency chain stored in makefile for a software
> project.
>
> Software projects is growing bigger and bigger nowadays. By adding this
> --dep features may also help developers not only to understand the 
> relationship
> between definitions in makefiles and also test if their makefile has problem
> (loop) in conditional checking for variables.
>
> Here comes the examples:
>
> Makefile:
>   A = AA
>   B = BB
>
>   ifeq ($(A),AA)
>   C = CC
>   endif
>
>   ifeq ($(A),AA)
>   D = DD
>   ifeq ($(B),BB)
>   C += CCC
>   endif
>   endif
>
>   ifeq ($(D),DD)
>   ifeq ($(B),BB)
>   E = EE
>   endif
>   endif
>
> Output of `make --dep`
> A = AA
> B = BB
> C = CC CCC
> value: CC, parent: A, value: AA;
> value: CCC, parent: A, value: AA; parent: B, value: BB;
> D = DD
> value: DD, parent: A, value: AA;
> E = EE
> value: EE, parent: D ,value DD; parent: B, value: BB;
> parent name: D, value: DD, parent: A, value AA;
>
>
> The following are some thought and futhur extension of current 
> implementations.
> 1. Since the make variable evaluation were stateless and no records stored.
> This implementation will use much more memory and linear search for linking 
> list
> to value_records and parent records.
> I think we can add something conditional checking if the "--dep" option has 
> been
> enabled. There is no need to maintain these records if "--dep" option was not
> enabled.
>
> 2. Loop detection and blacklists support.
> Actually, I've found some makefile will wrote like this.
>
>   A = AA
>   ifeq ($(A),)
>   A =
>   endif
>
> This kind of codes will lead a loop for a variable link a parents to itself.
> When dump all parents will cause a infinite loop.
> Some project may really need this kind of code for build.
> I think add a blacklist to avoid make to assign this kind of variable
> as parent could help.
>
> 3. Support print depth when dump dependency informations?
> If the dependency chain of a variable is very deep.
> Should we support the "depth" parameters to limits the depth of
> printing parents?
>
> 4. Print format.
> Is there any format could help developer or post scripts to parse the 
> dependency
> output more easily?
>
> 5. Test cases.
> I only write several makefile to test these patches.
> If there are official test cases, please tell me where they are and I can try
> them on current implementation.
>
> I think futher discussion is needed since I didn't very understand how 
> possible
> can this implementation help others in practice.
>
> Best regards,
> Macpaul Lin
>
> --
> Best regards,
> Macpaul Lin
>
> _______________________________________________
> Bug-make mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-make



-- 
You could help some brave and decent people to have access to
uncensored news by making a donation at:

http://www.thezimbabwean.co.uk/friends/