[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: win32 compilation of make 4.0 source code

From: Mark Brown
Subject: Re: win32 compilation of make 4.0 source code
Date: Mon, 27 Jan 2014 16:20:52 -0800

-----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?

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:
        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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]