Re: win32 compilation of make 4.0 source code
On Mon, Jan 27, 2014 at 11:05 PM, Mark Brown wrote: >> From: Paul Smith >> Sent: Monday, January 27, 2014 8:57 PM ... >> ifneq ($(filter else-if,$(.FEATURES)),else-if) >>$(error Version $(MAKE_VERSION) does not support else-if) >> endif > > Are you saying that this statement can be placed outside > of a make target recipe command sequence, > and would be executed before the target recipe command sequence ? The answer to your question can be found in the GNU make info pages. Or, you could just TRY IT AND GET THE ANSWER INSTANTLY. ... >> In GNU make 4.0 the --trace option was introduced. From the NEWS file: >> >> * New command line option: --trace enables tracing of targets. When >> enabled ... > Does this trace capability display the full evaluated automatic variables ? > Why not include a sample paste of its output. You've been unwilling to given any specific examples of your problems, makefile snippets, or output, and yet you question when other don't provide them? Since you obviously don't have the current version of make installed, why would anyone bother? Philip Guenther ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
-Original Message- From: Paul Smith Sent: Monday, January 27, 2014 8:57 PM To: Mark Brown Cc: bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code? On Mon, 2014-01-27 at 09:59 -0800, Mark Brown wrote: First, let me request that you include the question posed to you, in your Reply responses in this email sequence. This list, like almost all free software (and most technical public) mailing lists, prefers trimmed interleaved formats, and discourages top-posting. I leave in the parts of the previous email which are relevant to the response I provide, and cut out the rest. If you need to go back and look at previous messages every email to this list is archived in numerous locations available across the web. 1) I think my question was explicit. You may think so but it manifestly was not, since I provided an answer to exactly the question you asked, and that was not the answer you wanted. 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. The Makefile itself when e.g "make " 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 . I already showed "an example of .FEATURES display/echo in an existing Makefile." As for the new request: checking is simple, but you don't say what you want to do as a result of the check. What do you want to do if a feature is present? What do you want to do if a feature is not present? It's hard to give an example with no detail. In the interests of moving forward, here's some make code you can put in a makefile (not as part of a recipe; this is make syntax) which will cause it to exit with an error when the makefile is parsed if this version of make doesn't support the else-if construct: ifneq ($(filter else-if,$(.FEATURES)),else-if) $(error Version $(MAKE_VERSION) does not support else-if) endif Are you saying that this statement can be placed outside of a make target recipe command sequence, and would be executed before the target recipe command sequence ? Or would this statement have to be inserted in each and every Target recipe in each Makefile and subordinate Makefile ? Note the error function was introduced in GNU make 3.78 (released in 1999) so if you get a version older than that this won't fail. 2) Also, please answer the other question posed: --- 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. --- In GNU make 4.0 the --trace option was introduced. From the NEWS file: * New command line option: --trace enables tracing of targets. When enabled the recipe to be invoked is printed even if it would otherwise be suppressed by .SILENT or a "@" prefix character. Also before each recipe is run the makefile name and linenumber where it was defined are shown as well as the prerequisites that caused the target to be considered out of date. As for automatic variables, the values of those variables are (IMO) pretty clear by looking at the recipe line in the makefile versus the output that make prints, and/or just examining the target and prerequisites. Does this trace capability display the full evaluated automatic variables ? Why not include a sample paste of its output. re-paste of previous email contents again deleted [desired make trace output: ] $(CC) -c $(CFLAGS) $< -o $@ Make_filename Makefile_Line_Num auto_var_eval auto_var_eval /adir/bdir/cdir/Makefile554.mk1177 make_debug.c make_debug.o ... = ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Mon, 2014-01-27 at 09:59 -0800, Mark Brown wrote: > First, let me request that you include the question posed to you, > in your Reply responses in this email sequence. This list, like almost all free software (and most technical public) mailing lists, prefers trimmed interleaved formats, and discourages top-posting. I leave in the parts of the previous email which are relevant to the response I provide, and cut out the rest. If you need to go back and look at previous messages every email to this list is archived in numerous locations available across the web. > 1) I think my question was explicit. You may think so but it manifestly was not, since I provided an answer to exactly the question you asked, and that was not the answer you wanted. > 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. > The Makefile itself when e.g "make " 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 . I already showed "an example of .FEATURES display/echo in an existing Makefile." As for the new request: checking is simple, but you don't say what you want to do as a result of the check. What do you want to do if a feature is present? What do you want to do if a feature is not present? It's hard to give an example with no detail. In the interests of moving forward, here's some make code you can put in a makefile (not as part of a recipe; this is make syntax) which will cause it to exit with an error when the makefile is parsed if this version of make doesn't support the else-if construct: ifneq ($(filter else-if,$(.FEATURES)),else-if) $(error Version $(MAKE_VERSION) does not support else-if) endif Note the error function was introduced in GNU make 3.78 (released in 1999) so if you get a version older than that this won't fail. > 2) Also, please answer the other question posed: > --- > 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. > --- In GNU make 4.0 the --trace option was introduced. From the NEWS file: * New command line option: --trace enables tracing of targets. When enabled the recipe to be invoked is printed even if it would otherwise be suppressed by .SILENT or a "@" prefix character. Also before each recipe is run the makefile name and linenumber where it was defined are shown as well as the prerequisites that caused the target to be considered out of date. As for automatic variables, the values of those variables are (IMO) pretty clear by looking at the recipe line in the makefile versus the output that make prints, and/or just examining the target and prerequisites. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
-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 wrote:
On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown
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.
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}
Looks like you are saying here that such a test to inhibit all operations by
this Makefile
would have to be implemented on a Target by Target basis.
Sometimes there are scores of Targets in a Makefile or distributed Makefile,
within each of which this test would have to be performed.
So now you have a new question
The Makefile itself when e.g "make " 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.mk1177
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
Re: win32 compilation of make 4.0 source code
-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 wrote:
On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown
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.
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 " 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.mk1177
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 ‘$@’ and ‘$<’ ,
the evaluated result should be displayed along with the full pathname of the
current Makefile.
___
Re: win32 compilation of make 4.0 source code
(Dang it: gmail treats control-enter as "send"...)
On Mon, Jan 27, 2014 at 1:12 PM, Philip Guenther wrote:
> On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown 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.
>
> 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 ?
>
> 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 " 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.
>> 2) Also, please answer the other question posed:
Hmm, how much are you paying for these answers? Oh right, nothing...
>> ---
>>
>> 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/
>> 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
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Mon, Jan 27, 2014 at 9:59 AM, Mark Brown 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.
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 ?
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 " 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 .
>
> 2) Also, please answer the other question posed:
> ---
>
> 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.
> ---
>
> If either of these make capabilities are not possible currently,
> then that is a case for implementation in Make version 4.1 .
>
>
>
>
> -Original Message- From: Paul Smith
> Sent: Monday, January 27, 2014 9:35 AM
> To: Mark Brown
> Cc: bug-make@gnu.org
>
> Subject: Re: win32 compilation of make 4.0 source code
>
> On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote:
>>
>> That example method is a device to perform this .FEATURES test
>> without inserting it into an existing Makefile.
>> The syntax errors I was seeing were occurring when attempting to insert
>> this
>> test into an existing Makefile, full of Targets and command sequences.
>
>
> Well, since you've provided no details about exactly what you tried and
> what errors you received, or even details about exactly what you're
> trying to do, there's not much else we can say. You said "echo the
> data", and I showed an example of echoing the data. If that's not what
> you want, you need to give more information.
>
>
> ==re-pasted text of the question posed=
>
>
> That example method is a device to perform this .FEATURES test
> without inserting it into an existing Makefile.
> The syntax errors I was seeing were occurring when attempting to insert this
> test
> into an existing Makefile, full of Targets and command sequences.
> If this feature is used it would be at the top of an existing Makefile,
> before any targets
> are evaluated.
>
> 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.
> =
>
>
>
> ___
> Bug-make mailing list
> Bug-make@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-make
___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] output.c: Fix memory stomp when need==fmtbuf.size
No problem Paul, thanks for replying. I could've made it less intrusive by changing the test for whether to reallocate to: /* Make sure we have room. */ if (need >= fmtbuf.size) .. instead (so just a single '=' character change) but when I see "assert (fmtbuf.buffer[len] == '\0');" it doesn't sit well with me (looks like a bug at first glance) so I thought it better change it the way I did. Feel free to ask that I change to '>=', or just make that change yourself (provided you agree with my analysis that is). Cheers, Ray. On Mon, Jan 27, 2014 at 5:29 PM, Paul Smith wrote: > On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote: >> I missed a few assert cases in the previous patch. Please find a fixed >> version attached. > > Thanks Ray; I'm utterly swamped for the last week or so with "real life" > but I should have a bit more free time later this week; I'll check out > your fix. > > Cheers! > ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
First, let me request that you include the question posed to you, in your Reply responses in this email sequence. 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. The Makefile itself when e.g "make " 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 . 2) Also, please answer the other question posed: --- 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. --- If either of these make capabilities are not possible currently, then that is a case for implementation in Make version 4.1 . -Original Message- From: Paul Smith Sent: Monday, January 27, 2014 9:35 AM To: Mark Brown Cc: bug-make@gnu.org Subject: Re: win32 compilation of make 4.0 source code On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote: That example method is a device to perform this .FEATURES test without inserting it into an existing Makefile. The syntax errors I was seeing were occurring when attempting to insert this test into an existing Makefile, full of Targets and command sequences. Well, since you've provided no details about exactly what you tried and what errors you received, or even details about exactly what you're trying to do, there's not much else we can say. You said "echo the data", and I showed an example of echoing the data. If that's not what you want, you need to give more information. ==re-pasted text of the question posed= That example method is a device to perform this .FEATURES test without inserting it into an existing Makefile. The syntax errors I was seeing were occurring when attempting to insert this test into an existing Makefile, full of Targets and command sequences. If this feature is used it would be at the top of an existing Makefile, before any targets are evaluated. 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. = ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: [PATCH] output.c: Fix memory stomp when need==fmtbuf.size
On Sun, 2014-01-26 at 16:35 +, Ray Donnelly wrote: > I missed a few assert cases in the previous patch. Please find a fixed > version attached. Thanks Ray; I'm utterly swamped for the last week or so with "real life" but I should have a bit more free time later this week; I'll check out your fix. Cheers! ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
Re: win32 compilation of make 4.0 source code
On Sun, 2014-01-26 at 16:22 -0800, Mark Brown wrote: > That example method is a device to perform this .FEATURES test > without inserting it into an existing Makefile. > The syntax errors I was seeing were occurring when attempting to insert this > test into an existing Makefile, full of Targets and command sequences. Well, since you've provided no details about exactly what you tried and what errors you received, or even details about exactly what you're trying to do, there's not much else we can say. You said "echo the data", and I showed an example of echoing the data. If that's not what you want, you need to give more information. ___ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
