Re: win32 compilation of make 4.0 source code

[Mark Brown]

-----Original Message----- 
From: Philip Guenther
Sent: Monday, January 27, 2014 1:34 PM
To: Mark Brown
Cc: Paul Smith ; bug-make
Subject: Re: win32 compilation of make 4.0 source code

(Dang it: gmail treats control-enter as "send"...)
[Gmail is overrated. When I saw I could not free create folders and move 
messages
between them, I bailed on Gmail.]

On Mon, Jan 27, 2014 at 1:12 PM, Philip Guenther <address@hidden> wrote:
> On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown <address@hidden> 
> wrote:
> > First, let me request that you include the question posed to you,
> > in your Reply responses in this email sequence.
>
> How about you stop top-posting and instead reply inline?
Ok.

> > 1)  I think my question was explicit.
> > A method for an existing Makefile to test for .FEATURES capabilities
> > when it is downloaded to a random linux or Windows make environment
> > and existed.
> <sigh> That wasn't the question you originally asked.  To quote your
> original query about .FEATURES:

> > > As a separate related issue,
> > > I was try to echo the .FEATURES information, since one of the its it 
> > > claims to display
> > > mentions its Else If capabilities.
> > > However, every time I tried to echo the data I received a syntax error.
> > > What would be an example of a Makefile contents which would display
> > > the .FEATURES information ?
"Makefile contents" is operative here.

> The example that Paul gave answers that original question:
> all:
>         echo ${.FEATURES}

> So now you have a new question
>
> > The Makefile itself when e.g "make <target>" is selected, should be
> > able to precede execution of any target with a check of .FEATURES
> > to verify the make environment into which it is downloaded.
> > Give an example of .FEATURES display/echo in an existing Makefile.,
> > both v 3.80 and 4.00 .

> This is where Paul question of "what did you already try?" comes in.
> Rather than give you a fish, it would be better to teach you how to
> fish; seeing what you tried would let us correct whatever
> misunderstanding caused the syntax errors you got.

> Or you could search the archives for examples, if you really don't
> want to understand.

I tried -d (which equates to turning on all debug flags)
and did not find the trace of a source file or the corresponding output file
which I could see being generated when I deleted the output file each time.
The particular build I performed generated a 3.2 GBytes file which had to
be split into 5 portions to search each one.

> > 2)  Also, please answer the other question posed:
> Hmm, how much are you paying for these answers?  Oh right, nothing...

I am presenting features that are needed in the Make project for general 
usage.

> > ---------------------------------------------------------------------------------------------------
> >
> > I also want to know if there is a debug mode within make
> > in which the Makefile filename and Line Number
> > (some Makefiles are huge and distributed over several subordinate 
> > Makefiles)
> > is matched to each automatic variable evaluation within a Target 
> > evaluation.
> > ---------------------------------------------------------------------------------------------------

Since you don't say what debug output you've already looked at, I'll
just suggest two possibilities
1) "make -pq" and examine the dumped output, which gives file and line
number for all commands
2) check out the "remake" project. http://bashdb.sourceforge.net/remake/

Make documentation indicates that -d would include -p and -q .
However, the specific information I am looking for should be readily 
available.
i.e. make -h  should highlight the flag which delivers the result I have 
described.
$(CC) -c $(CFLAGS) $< -o $@

Make_filename                               Makefile_Line_Num 
auto_var_eval   auto_var_eval
/adir/bdir/cdir/Makefile554.mk                    1177 
make_debug.c   make_debug.o
...
...
The current directory would be implied by the Makefile full pathname.

> > If either of these make capabilities are not possible currently,
> > then that is a case for implementation in  Make  version 4.1 .

> You didn't describe the problem that you're trying to solve; how do
> you know that data would solve it?  Why *only* automatic variables?
> If there are several levels of variable expansion involved, what
> should the output look like?
> Philip Guenther

Whenever I use Make on an existing big project,
the information about where a particular source file is compiled
is the main thing I want to know.
Usually, this affects how additional files could be added to the executable 
or library
related to a particular file.
As mentioned, I searched the whole -d output and did not see particular .c 
sources,
for which the .o or .so  I knew were being generated by operation of make.

Automatic variable resolution has an eventual end and I am sure the make 
parser is aware
when there are no more variable fields within a token string, .
At that point, especially for  automatic variables like address@hidden and ‘$<’ 
 ,
the evaluated result should be displayed along with the full pathname of the 
current Makefile.