[bug #38945] [PATCH] Fix CRLF backslash-newline handing on non-WINDOWS32 platforms

[Diego Biurrun]

Follow-up Comment #4, bug #38945 (project make):

Here's a minimal testcase to reproduce this bug.

Put the following in "Makefile" (Unix or DOS linebreaks):

include snippet

define RULES
clean::
$(RM) $(OBJS) $(OBJS:.o=.d)
endef
$(eval $(RULES))

Put the following in "snippet" (DOS linebreaks):

OBJS = x86/cpu.o 

There must not be an empty line after OBJS in "snippet", otherwise the bug
will not trigger.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #38442] Field 'name' not cached

[Paul D. Smith]

Follow-up Comment #5, bug #38442 (project make):

No, it's an internal make error.  I don't see how it could be an ar issue. 
I'll try to repro it again.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #38442] Field 'name' not cached

[Gökçe]

Follow-up Comment #4, bug #38442 (project make):

Unfortunately still the same error:

$ touch foo.vhd
$ make-3.99.90/make
cd module_timestamps && touch foo && ar rv lib foo && rm foo
ar: creating lib
a - foo
$ make-3.99.90/make
make: Nothing to be done for 'default'.
make: module_timestamps/lib(foo): Field 'name' not cached:
module_timestamps/lib(foo)

make: module_timestamps/lib(foo): Field 'hname' not cached:
module_timestamps/lib(foo)


Maybe the problem is with ar? I am going to test the issue on another system
with different binutils.


kara@ed:~/Downloads$ ar --version
GNU ar (GNU Binutils) 2.23.2
...


Last but not least, it would be great to know the meaning of this warning.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #26596] MAKEFLAGS documentation tweak

[Stefano Lattarini]

On 05/22/2013 06:56 PM, Paul Smith wrote:
> On Wed, 2013-05-22 at 17:42 +0200, Stefano Lattarini wrote:
>> Hi Paul.
>>
>> On 05/22/2013 05:17 PM, Paul D. Smith wrote:
>>> Follow-up Comment #1, bug #26596 (project make):
>>>
>>> Hm.  I'm not sure why the immediate expansion has limited content.  Is there
>>> any purpose to this?  Wouldn't it just be better to have the immediate
>>> expansion resolve to the entire thing?  I'll have to look into it; maybe
>>> there's a good reason for doing it this way.
>>>
>> FWIW, the current behavior of $(MFLAGS) and $(MAKEFLAGS) is used as a
>> feature in Automake-NG (my Automake fork that assumes the generated
>> makefiles will only be run by GNU make); see the comments about the
>> 'am.make.is-running-with-option' macro in
>> 
>> Changing it will probably break something there :-(
> 
> Perhaps... I'm not sure.
> 
>> But maybe, are you willing to implement new macro(s) that makes is
>> easier to probe at runtime, from within the makefiles, the flags
>> passed to GNU make?  In that case, I'd be more than willing to adjust
>> Automake and/or Automake-NG to take advantage of that.
> 
> I've reworked the MFLAGS / MAKEFLAGS generation to be more regular and
> rigorous yesterday, for 4.0, and to preserve _some_ backward-compat; I
> had thought about this issue when I did so.  Please comment on the
> rules:
>
I'll rework your wording to reference mostly MFLAGS, since that is what
both mainline Automake and Automake-NG currently use.

> For MFLAGS:
>  1. In all cases where an option has both single-letter and long
> formats, the single-letter format will be used regardless of
> what appeared on the command line.  Single-letter/no argument
> options they will always be preceded by a "-".
>
This is good.

>  2. If there are no options or variable assignments for MAKEFLAGS,
> it will resolve to the empty string.
>
And I assume that variable assignments will still *not* be placed in
$(MFLAGS), right?  Automake has so far been relying on that utterly.

> 2a. If there are no single-letter / no argument options, the whole
> section is not present (i.e., no leading single dash, no leading
> space, etc.)
OK.

>  3. Any single-letter / no argument options will always be in the
> first word; there will be no "-" prefix to this word
>
Even for MFLAGS?  That would be a bad, backward-incompatible change.
But I see this is not the case luckily:

  $ make -f- -Ifoo -k -i  <<<'all:; @echo "$$MFLAGS"'
  -ik -Ifoo

so I must have misunderstand you.

>  5. Next, any options that have single-letter variations but take
> arguments (optional or not) will appear, as " -X[arg]" (these
> can never be combined).
>
Indeed, the current behaviour of GNU make 3.82:

$ make -f- <<<'all:; @echo $(MFLAGS)' -Ifoo -k -i
   -kI foo -i

is now superseded by this one (IMHO much clearer and more manageable):

$ make -f- <<<'all:; @echo $(MFLAGS)' -Id -k -i
-ki -Ifoo

That change don't have any effect on Automake AFAICS, so no objection
from me.

>  6. Next any options that have only long names, with or without
> arguments, will appear, as " --OPTION[=arg]".
> 
> For some reason, --eval options are not added to MFLAGS.  That might be
> a bug.
> 
> As a result, it should be completely reliable to use something like this
> to test for single-character, no argument options:
> 
>   $(if $(findstring k,$(firstword -$(MAKEFLAGS))),found k,no k)
>
Is this tested in the GNU make testsuite?  I'd love such a simple, sane
behavior not to regress involuntarily.

> Similarly you can test for single-character, argument options like this:
> 
>   $(if $(filter -I%,$(MAKEFLAGS)),found -I, no -I)
>
Ditto.

> And long options like this:
> 
>   $(if $(filter --trace%,$(MAKEFLAGS)),found --trace,no --trace)
>
Aren't you missing a '=' after '--trace' here.  Other than that, this
seems good as well.

> I understand that from a backward-compatibility standpoint relying on
> this behavior is problematic.
> 
The important thing for me is that the new behavior doesn't break the
existing idioms employed by Automake.  I've run the Automake testsuite
with the latest GNU make from git (both for mainline Automake and for
Automake-NG), and found no regression, so I can declare myself happy
for the moment.

Thanks,
  Stefano

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #38442] Field 'name' not cached

[Paul D. Smith]

Follow-up Comment #3, bug #38442 (project make):

Can you please test with the current release candidate build and see if you
still see the issue?  I cannot reproduce it.

ftp://alpha.gnu.org/gnu/make/make-3.99.90.tar.gz

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: Documentation for the eval function

[Paul Smith]

On Wed, 2013-05-22 at 20:13 +0200, Sascha Ziemann wrote:
> Hi,
> 
> I think the example in the documentation for the eval function is
> broken. I copied the example to a file and tried it with "make clean".
> The action for the clean target is "rm -f $(ALL_OBJS) $(PROGRAMS)".
> The PROGRAMS variable is set at the beginning to "server client" and
> the ALL_OBJS variable should be filled by the foreach call of the eval
> function. Because of that I think that the intended action for the
> clean target is "rm -f server.o server_priv.o server_access.o client.o
> client_api.o client_mem.o server client". But when I try the example I
> get the following output:
> 
> make clean
> rm -f  server client
> 
> So I think the example must be wrong, isn't it?

No.  The example works.

Please run "make --version".  The online manual documents the currently
released version of GNU make.  The eval function was added in GNU make
3.80, which was released in 2002.  If your version of GNU make is older
than that, then $(eval ...) will not work for you.

If your version is 3.80 or newer, please cut/paste (exactly) your
makefile so we can see it.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Documentation for the eval function

[Sascha Ziemann]

Hi,

I think the example in the documentation for the eval function is
broken. I copied the example to a file and tried it with "make clean".
The action for the clean target is "rm -f $(ALL_OBJS) $(PROGRAMS)".
The PROGRAMS variable is set at the beginning to "server client" and
the ALL_OBJS variable should be filled by the foreach call of the eval
function. Because of that I think that the intended action for the
clean target is "rm -f server.o server_priv.o server_access.o client.o
client_api.o client_mem.o server client". But when I try the example I
get the following output:

make clean
rm -f  server client

So I think the example must be wrong, isn't it?

Regards
Sascha

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #38945] [PATCH] Fix CRLF backslash-newline handing on non-WINDOWS32 platforms

[Derek Buitenhuis]

Follow-up Comment #3, bug #38945 (project make):

I'm actually having a hard time making a small reproducible file...

At the moment, you can easily reproduce this as:

$ git clone git://git.libav.org/libav.git
$ cd libav
$ ./configure
$ todos libavcodec/x86/Makefile
$ make
common.mak:65: *** missing separator.  Stop.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #26596] MAKEFLAGS documentation tweak

[Paul Smith]

On Wed, 2013-05-22 at 17:42 +0200, Stefano Lattarini wrote:
> Hi Paul.
> 
> On 05/22/2013 05:17 PM, Paul D. Smith wrote:
> > Follow-up Comment #1, bug #26596 (project make):
> > 
> > Hm.  I'm not sure why the immediate expansion has limited content.  Is there
> > any purpose to this?  Wouldn't it just be better to have the immediate
> > expansion resolve to the entire thing?  I'll have to look into it; maybe
> > there's a good reason for doing it this way.
> >
> FWIW, the current behavior of $(MFLAGS) and $(MAKEFLAGS) is used as a
> feature in Automake-NG (my Automake fork that assumes the generated
> makefiles will only be run by GNU make); see the comments about the
> 'am.make.is-running-with-option' macro in
> 
> Changing it will probably break something there :-(

Perhaps... I'm not sure.

> But maybe, are you willing to implement new macro(s) that makes is
> easier to probe at runtime, from within the makefiles, the flags
> passed to GNU make?  In that case, I'd be more than willing to adjust
> Automake and/or Automake-NG to take advantage of that.

I've reworked the MFLAGS / MAKEFLAGS generation to be more regular and
rigorous yesterday, for 4.0, and to preserve _some_ backward-compat; I
had thought about this issue when I did so.  Please comment on the
rules:

For MAKEFLAGS:
 1. In all cases where an option has both single-letter and long
formats, the single-letter format will be used regardless of
what appeared on the command line.
 2. If there are no options or variable assignments for MAKEFLAGS,
it will resolve to the empty string.
 3. Any single-letter / no argument options will always be in the
first word; there will be no "-" prefix to this word
 4. If there are no single-letter / no argument options, the first
character in MAKEFLAGS will be a space.
 5. Next, any options that have single-letter variations but take
arguments (optional or not) will appear, as " -X[arg]" (these
can never be combined).
 6. Next any options that have only long names, with or without
arguments, will appear, as " --OPTION[=arg]".
 7. Next, any --eval options appear.
 8. Finally if there are any variable assignments, " -- " will be
added followed by the variable assignments
 9. All arguments above are quoted as needed by GNU make to parse
them from the environment

For MFLAGS:
 1. Rules 1-3,5,6 above hold, except that if there are
single-letter/no argument options they will always be preceded
by a "-".
 2. If there are no single-letter / no argument options, the whole
section is not present (i.e., no leading single dash, no leading
space, etc.)

For some reason, --eval options are not added to MFLAGS.  That might be
a bug.

As a result, it should be completely reliable to use something like this
to test for single-character, no argument options:

  $(if $(findstring k,$(firstword -$(MAKEFLAGS))),found k,no k)

Similarly you can test for single-character, argument options like this:

  $(if $(filter -I%,$(MAKEFLAGS)),found -I, no -I)

And long options like this:

  $(if $(filter --trace%,$(MAKEFLAGS)),found --trace,no --trace)

I understand that from a backward-compatibility standpoint relying on
this behavior is problematic.


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Re: [bug #26596] MAKEFLAGS documentation tweak

[Stefano Lattarini]

Hi Paul.

On 05/22/2013 05:17 PM, Paul D. Smith wrote:
> Follow-up Comment #1, bug #26596 (project make):
> 
> Hm.  I'm not sure why the immediate expansion has limited content.  Is there
> any purpose to this?  Wouldn't it just be better to have the immediate
> expansion resolve to the entire thing?  I'll have to look into it; maybe
> there's a good reason for doing it this way.
>
FWIW, the current behavior of $(MFLAGS) and $(MAKEFLAGS) is used as a
feature in Automake-NG (my Automake fork that assumes the generated
makefiles will only be run by GNU make); see the comments about the
'am.make.is-running-with-option' macro in

Changing it will probably break something there :-(

But maybe, are you willing to implement new macro(s) that makes is
easier to probe at runtime, from within the makefiles, the flags
passed to GNU make?  In that case, I'd be more than willing to adjust
Automake and/or Automake-NG to take advantage of that.

Regards,
  Stefano

___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #38945] [PATCH] Fix CRLF backslash-newline handing on non-WINDOWS32 platforms

[Paul D. Smith]

Update of bug #38945 (project make):

   Triage Status:None => Need Info  

___

Follow-up Comment #2:

I'm trying to create a repro case for this.  I've created a file on Linux and
forced it to contain CRLF line endings but I can't get it to fail with the
errors you've described.  I'm not sure what you mean by "a rule/prefix name",
and the makefile you point to as an example case doesn't contain any rules:
it's simply a long list of variable assignments.  The name of that file
doesn't match the error message you give, and there aren't 129 lines in that
file, so that message is from a different file.

Can you attach a small, simple makefile to the bug that shows the error?

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #26596] MAKEFLAGS documentation tweak

[Paul D. Smith]

Follow-up Comment #1, bug #26596 (project make):

Hm.  I'm not sure why the immediate expansion has limited content.  Is there
any purpose to this?  Wouldn't it just be better to have the immediate
expansion resolve to the entire thing?  I'll have to look into it; maybe
there's a good reason for doing it this way.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #39035] problem with blanks in continuation line in a recipe

[anonymous]

URL:
  

 Summary: problem with blanks in continuation line in a recipe
 Project: make
Submitted by: None
Submitted on: Wed 22 May 2013 08:35:08 AM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.82
Operating System: POSIX-Based
   Fixed Release: None
   Triage Status: None

___

Details:

See
[http://stackoverflow.com/questions/16659294/different-output-in-makefile-rule]

In the following Makefile


f = echo $(1)

t:
   $(call f,"a \
b"); \
$(call f,"a \
b")


 * there is only one TAB, at the beginning of line 4 (the first
   `call f')
 * no blanks at the end of the lines
 * > 8 blanks in line 5 (12 in the example, no problem if <= 8)

The output is


a b
a  b


The two calls are identical (except for the initial TAB). Why the output are
different ?





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make