GNU bug report logs - #7824
1.11 doesn't add sources with nonstandard suffixes when making a binary

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 7824 in the body.
You can then email your comments to 7824 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Ralf.Wildenhues <at> gmx.de, bug-automake <at> gnu.org
Subject: Re: 1.11 doesn't add sources with nonstandard suffixes when making a
	binary
Date: Tue, 11 Jan 2011 17:48:08 +0300

Good day, Ralf!

I've (finally) made it through two implicit rules, but i have a problem there.

The makefile looks something like that:

------------------------
.SUFFIXES: .pc .lo .c
.pc.c:
	cp $< $@
.c.lo:
	cp $< $@
------------------------

Given that i have no .c and no .lo before invoking make, it works good
with gmake and aix make.
While on HP-UX it doesn't:
--- skipped some lines of setting vars ---
Reading Makefile
doname(a.lo,0)
TIME(a.lo)=0
setvar: @ = a.lo noreset = 0 envflg = 0 Mflags = 040001
setvar: @ =  noreset = 0 envflg = 0 Mflags = 040001
look for explicit deps. 0
look for implicit rules. 0
right match = a.lo
setvar: @ = a.lo noreset = 0 envflg = 0 Mflags = 040001
setvar: ? =  noreset = 0 envflg = 0 Mflags = 040001
predecessor list: $! =  a.lo
right match = a.lo
setvar: @ = a.lo noreset = 0 envflg = 0 Mflags = 040001
setvar: ? =  noreset = 0 envflg = 0 Mflags = 040001
predecessor list: $! =  a.lo
Make: Don't know how to make a.lo.  Stop.
--------------------------------------

If .c file is present, it works:

-------------------------------------
doname(a.lo,0)
TIME(a.lo)=0
setvar: @ = a.lo noreset = 0 envflg = 0 Mflags = 040001
setvar: @ =  noreset = 0 envflg = 0 Mflags = 040001
look for explicit deps. 0
look for implicit rules. 0
right match = a.lo
a.c ---.c.lo--- a.lo
   doname(a.c,1)
setvar: @ = a.c noreset = 0 envflg = 0 Mflags = 040001
setvar: @ =  noreset = 0 envflg = 0 Mflags = 040001
   look for explicit deps. 1
   look for implicit rules. 1
   right match = a.c
   a.pc ---.pc.c--- a.c
      doname(a.pc,2)
setvar: @ = a.pc noreset = 0 envflg = 0 Mflags = 040001
setvar: @ =  noreset = 0 envflg = 0 Mflags = 040001
      look for explicit deps. 2
      look for implicit rules. 2
      right match = a.pc
setvar: < =  noreset = 0 envflg = 0 Mflags = 040001
setvar: * =  noreset = 0 envflg = 0 Mflags = 040001
   TIME(a.pc)=1294756730
setvar: * = a noreset = 0 envflg = 0 Mflags = 040001
setvar: < = a.pc noreset = 0 envflg = 0 Mflags = 040001
setvar: < =  noreset = 0 envflg = 0 Mflags = 040001
setvar: * =  noreset = 0 envflg = 0 Mflags = 040001
TIME(a.c)=1294757269
setvar: * = a noreset = 0 envflg = 0 Mflags = 040001
setvar: < = a.c noreset = 0 envflg = 0 Mflags = 040001
setvar: @ = a.lo noreset = 0 envflg = 0 Mflags = 040001
setvar: ? = a.c noreset = 0 envflg = 0 Mflags = 040001
predecessor list: $! =  a.lo
        cp a.c a.lo
nenv = 34
setvar: @ =  noreset = 0 envflg = 0 Mflags = 040001
setvar: % =  noreset = 0 envflg = 0 Mflags = 040001
setvar: < =  noreset = 0 envflg = 0 Mflags = 040001
setvar: * =  noreset = 0 envflg = 0 Mflags = 040001
-------------------------------------

Maybe You know a way to do it right?


On Sat, Nov 28, 2009 at 12:50 AM, Ralf Wildenhues
<Ralf.Wildenhues <at> gmx.de> wrote:
> Hi Jack,
>
> * Jack Kelly wrote on Fri, Nov 27, 2009 at 10:37:55PM CET:
>> 2009/11/28 Ralf Wildenhues:
>> > That's why you should do it like this:
>> >
>> > .pc.$(OBJEXT):
>> >        ...
>>
>> I'm confused. Why is this better than writing a .pc.c rule? Doesn't it
>> sacrifice proper dependency tracking on the generated .c file?
>
> Because it's late and I avoid caffeine in the evening.  ;-)
> Of course, .pc.c.
>
> Thanks,
> Ralf
>
>
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>
To: Юрий Пухальский <aikipooh <at> gmail.com>
Cc: bug-automake <at> gnu.org
Subject: Re: 1.11 doesn't add sources with nonstandard suffixes when making a
	binary
Date: Tue, 11 Jan 2011 21:35:31 +0100

Hello Юрий,

* Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET:
> I've (finally) made it through two implicit rules, but i have a problem there.
> 
> The makefile looks something like that:
> 
> ------------------------
> .SUFFIXES: .pc .lo .c
> .pc.c:
> 	cp $< $@
> .c.lo:
> 	cp $< $@
> ------------------------
> 
> Given that i have no .c and no .lo before invoking make, it works good
> with gmake and aix make.
> While on HP-UX it doesn't:

Yep, that's because some non-GNU makes don't close suffix rules
transitively.  You can either add explicit stub dependencies
  foo.lo: foo.c
  bar.lo: bar.c
  ...

or you can add a .pc.lo rule that contains the commands from both other
rules.  Or require a decent make.  ;-)

Cheers,
Ralf

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: bug-automake <at> gnu.org, "ralf.wildenhues" <ralf.wildenhues <at> gmx.de>
Subject: Re: 1.11 doesn't add sources with nonstandard suffixes when making a
	binary
Date: Tue, 11 Jan 2011 23:43:07 +0300

2011/1/11 Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>:
> Hello Юрий,
>
> * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET:
>> I've (finally) made it through two implicit rules, but i have a problem there.
>>
>> The makefile looks something like that:
>>
>> ------------------------
>> .SUFFIXES: .pc .lo .c
>> .pc.c:
>>       cp $< $@
>> .c.lo:
>>       cp $< $@
>> ------------------------
>>
>> Given that i have no .c and no .lo before invoking make, it works good
>> with gmake and aix make.
>> While on HP-UX it doesn't:
>
> Yep, that's because some non-GNU makes don't close suffix rules
> transitively.  You can either add explicit stub dependencies
>  foo.lo: foo.c
>  bar.lo: bar.c
They are too many... And this is a crud.
But as i read a standard, i understand, the rules must be transitive.
As there's stated that if there is no explicit rule, we use implicit,
thus in this case requiring to rebuild foo.c. Then we apply the same
logic and get to foo.pc to foo.c implicit rule, no?

>  ...
>
> or you can add a .pc.lo rule that contains the commands from both other
> rules.  Or require a decent make.  ;-)
That was what i started with:) But as there were problems i was
advised to use .pc.c rule...

>
> Cheers,
> Ralf
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: bug-automake <at> gnu.org, "ralf.wildenhues" <ralf.wildenhues <at> gmx.de>
Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes when
	making a binary
Date: Wed, 12 Jan 2011 17:21:11 +0300

So i put it all together.

If i have a Makefile like this:
-----------------------------
SUFFIXES = .pc

.pc.lo:
	cp $(srcdir)/$*.pc $(builddir)/$*.c
	$(LTCOMPILE) -c $(builddir)/$*.c
	rm -f $(builddir)/$*.c

noinst_PROGRAMS = 1 2

1_SOURCES = 1.pc

db_src = 1.pc
2_SOURCES = dummy.c
2_LDADD = $(db_src:.pc=.lo)
-----------------------------
1 is not built:
--------------------------------
devfe:~/tmp/test>make
/bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
libtool: link: gcc -g -O2 -o 1
gcc: no input files
make: *** [1] Error 1
--------------------------------

If i make a rule .pc.c, then i have problem on HP-UX.

I'd say the first approach is legitimate - i make whatever rule i
want, i use .pc in SOURCES, and automake should take care of
everything else, like it's stated in the doc?
Second approach is ok too - for i don't see any limitation on
transitive rules in standard.

On the other hand, putting explicit dependencies in case of makes like
that on HP-UX could be done in automake. It's cruddy to do it
manually...

Can You comment on this?

PS. If one can use a decent make, there is no need for automake:)))

2011/1/11 Юрий Пухальский <aikipooh <at> gmail.com>:
> 2011/1/11 Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>:
>> Hello Юрий,
>>
>> * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET:
>>> I've (finally) made it through two implicit rules, but i have a problem there.
>>>
>>> The makefile looks something like that:
>>>
>>> ------------------------
>>> .SUFFIXES: .pc .lo .c
>>> .pc.c:
>>>       cp $< $@
>>> .c.lo:
>>>       cp $< $@
>>> ------------------------
>>>
>>> Given that i have no .c and no .lo before invoking make, it works good
>>> with gmake and aix make.
>>> While on HP-UX it doesn't:
>>
>> Yep, that's because some non-GNU makes don't close suffix rules
>> transitively.  You can either add explicit stub dependencies
>>  foo.lo: foo.c
>>  bar.lo: bar.c
> They are too many... And this is a crud.
> But as i read a standard, i understand, the rules must be transitive.
> As there's stated that if there is no explicit rule, we use implicit,
> thus in this case requiring to rebuild foo.c. Then we apply the same
> logic and get to foo.pc to foo.c implicit rule, no?
>
>>  ...
>>
>> or you can add a .pc.lo rule that contains the commands from both other
>> rules.  Or require a decent make.  ;-)
> That was what i started with:) But as there were problems i was
> advised to use .pc.c rule...
>
>>
>> Cheers,
>> Ralf
>>
>
>
>
> --
> «The good thing about standards is there are so many to choose from.»
>
>
>
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #17 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7824 <at> debbugs.gnu.org
Cc: Юрий Пухальский <aikipooh <at> gmail.com>,
	"ralf.wildenhues" <ralf.wildenhues <at> gmx.de>
Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes when
	making a binary
Date: Wed, 12 Jan 2011 15:46:39 +0100

Hello Юрий.

On Wednesday 12 January 2011, Юрий Пухальский wrote:
> So i put it all together.
> 
> If i have a Makefile like this:
> -----------------------------
> SUFFIXES = .pc
> 
> .pc.lo:
> 	cp $(srcdir)/$*.pc $(builddir)/$*.c
> 	$(LTCOMPILE) -c $(builddir)/$*.c
> 	rm -f $(builddir)/$*.c
> 
> noinst_PROGRAMS = 1 2
> 
> 1_SOURCES = 1.pc
> 
> db_src = 1.pc
> 2_SOURCES = dummy.c
> 2_LDADD = $(db_src:.pc=.lo)
> -----------------------------
> 1 is not built:
> --------------------------------
> devfe:~/tmp/test>make
> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
> libtool: link: gcc -g -O2 -o 1
> gcc: no input files
> make: *** [1] Error 1
> --------------------------------
> 
> If i make a rule .pc.c, then i have problem on HP-UX.
> 
> I'd say the first approach is legitimate - i make whatever rule i
> want, i use .pc in SOURCES, and automake should take care of
> everything else, like it's stated in the doc?
> Second approach is ok too - for i don't see any limitation on
> transitive rules in standard.
> 
> On the other hand, putting explicit dependencies in case of makes like
> that on HP-UX could be done in automake. It's cruddy to do it
> manually...
> 
> Can You comment on this?
> 
> PS. If one can use a decent make, there is no need for automake:)))
>
Just a quick note: you might want to take a look at automake bug#7670:
 <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7670>
 <http://lists.gnu.org/archive/html/bug-automake/2010-12/msg00034.html>
which is closely related to yours.

(BTW, these two bug reports are so similar that they should probably
be merged).

Regards,
  Stefano

Message #20 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: "ralf.wildenhues" <ralf.wildenhues <at> gmx.de>, 7824 <at> debbugs.gnu.org
Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes when
	making a binary
Date: Wed, 12 Jan 2011 18:28:10 +0300

Aye, looks like it.

I have no objections whatsoever, i just need some method to make it
work, because it's my working project:)
So no problem with me to join together these reports.

2011/1/12 Stefano Lattarini <stefano.lattarini <at> gmail.com>:
> Hello Юрий.
>
> On Wednesday 12 January 2011, Юрий Пухальский wrote:
>> So i put it all together.
>>
>> If i have a Makefile like this:
>> -----------------------------
>> SUFFIXES = .pc
>>
>> .pc.lo:
>>       cp $(srcdir)/$*.pc $(builddir)/$*.c
>>       $(LTCOMPILE) -c $(builddir)/$*.c
>>       rm -f $(builddir)/$*.c
>>
>> noinst_PROGRAMS = 1 2
>>
>> 1_SOURCES = 1.pc
>>
>> db_src = 1.pc
>> 2_SOURCES = dummy.c
>> 2_LDADD = $(db_src:.pc=.lo)
>> -----------------------------
>> 1 is not built:
>> --------------------------------
>> devfe:~/tmp/test>make
>> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
>> libtool: link: gcc -g -O2 -o 1
>> gcc: no input files
>> make: *** [1] Error 1
>> --------------------------------
>>
>> If i make a rule .pc.c, then i have problem on HP-UX.
>>
>> I'd say the first approach is legitimate - i make whatever rule i
>> want, i use .pc in SOURCES, and automake should take care of
>> everything else, like it's stated in the doc?
>> Second approach is ok too - for i don't see any limitation on
>> transitive rules in standard.
>>
>> On the other hand, putting explicit dependencies in case of makes like
>> that on HP-UX could be done in automake. It's cruddy to do it
>> manually...
>>
>> Can You comment on this?
>>
>> PS. If one can use a decent make, there is no need for automake:)))
>>
> Just a quick note: you might want to take a look at automake bug#7670:
>  <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7670>
>  <http://lists.gnu.org/archive/html/bug-automake/2010-12/msg00034.html>
> which is closely related to yours.
>
> (BTW, these two bug reports are so similar that they should probably
> be merged).
>
> Regards,
>  Stefano
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #27 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "ralf.wildenhues" <ralf.wildenhues <at> gmx.de>
To: Юрий Пухальский <aikipooh <at> gmail.com>
Cc: bug-automake <at> gnu.org
Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes
	when making a binary
Date: Thu, 13 Jan 2011 20:07:41 +0100

* Юрий Пухальский wrote on Wed, Jan 12, 2011 at 03:21:11PM CET:
> -----------------------------
> SUFFIXES = .pc
> 
> .pc.lo:
> 	cp $(srcdir)/$*.pc $(builddir)/$*.c
> 	$(LTCOMPILE) -c $(builddir)/$*.c
> 	rm -f $(builddir)/$*.c
> 
> noinst_PROGRAMS = 1 2
> 
> 1_SOURCES = 1.pc

Program sources are not compiled into .lo files, but into .$(OBJEXT)
files.  So you would need a .pc.$(OBJEXT) rule.  You can use $(COMPILE)
instead of $(LTCOMPILE).

> db_src = 1.pc
> 2_SOURCES = dummy.c
> 2_LDADD = $(db_src:.pc=.lo)
> -----------------------------
> 1 is not built:
> --------------------------------
> devfe:~/tmp/test>make
> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
> libtool: link: gcc -g -O2 -o 1
> gcc: no input files
> make: *** [1] Error 1

Message #30 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Юрий Пухальский <aikipooh <at> gmail.com>, 
	bug-automake <at> gnu.org
Subject: Re: bug#7824: 1.11 doesn't add sources with nonstandard suffixes when
	making a binary
Date: Thu, 13 Jan 2011 22:26:31 +0300

Ah, sorry. That's so easy, and now i recollect you must have said this
before, but i've lost it...

2011/1/13 ralf.wildenhues <ralf.wildenhues <at> gmx.de>:
> * Юрий Пухальский wrote on Wed, Jan 12, 2011 at 03:21:11PM CET:
>> -----------------------------
>> SUFFIXES = .pc
>>
>> .pc.lo:
>>       cp $(srcdir)/$*.pc $(builddir)/$*.c
>>       $(LTCOMPILE) -c $(builddir)/$*.c
>>       rm -f $(builddir)/$*.c
>>
>> noinst_PROGRAMS = 1 2
>>
>> 1_SOURCES = 1.pc
>
> Program sources are not compiled into .lo files, but into .$(OBJEXT)
> files.  So you would need a .pc.$(OBJEXT) rule.  You can use $(COMPILE)
> instead of $(LTCOMPILE).
>
>> db_src = 1.pc
>> 2_SOURCES = dummy.c
>> 2_LDADD = $(db_src:.pc=.lo)
>> -----------------------------
>> 1 is not built:
>> --------------------------------
>> devfe:~/tmp/test>make
>> /bin/sh ./libtool --tag=CC   --mode=link gcc  -g -O2   -o 1
>> libtool: link: gcc -g -O2 -o 1
>> gcc: no input files
>> make: *** [1] Error 1
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #33 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Ralf.Wildenhues <at> gmx.de, bug-automake <at> gnu.org
Subject: Re: 1.11 doesn't add sources with nonstandard suffixes when making a
	binary
Date: Wed, 26 Jan 2011 13:23:42 +0300

Good day, Ralf!

.pc.lo compiles but there is no tags rule being generated. With .pc.c
rule tags are ok.

So still there is a problem somewhere...

2011/1/11 Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de>:
> Hello Юрий,
>
> * Юрий Пухальский wrote on Tue, Jan 11, 2011 at 03:48:08PM CET:
>> I've (finally) made it through two implicit rules, but i have a problem there.
>>
>> The makefile looks something like that:
>>
>> ------------------------
>> .SUFFIXES: .pc .lo .c
>> .pc.c:
>>       cp $< $@
>> .c.lo:
>>       cp $< $@
>> ------------------------
>>
>> Given that i have no .c and no .lo before invoking make, it works good
>> with gmake and aix make.
>> While on HP-UX it doesn't:
>
> Yep, that's because some non-GNU makes don't close suffix rules
> transitively.  You can either add explicit stub dependencies
>  foo.lo: foo.c
>  bar.lo: bar.c
>  ...
>
> or you can add a .pc.lo rule that contains the commands from both other
> rules.  Or require a decent make.  ;-)
>
> Cheers,
> Ralf
>



-- 
«The good thing about standards is there are so many to choose from.»

Message #36 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: 7824 <at> debbugs.gnu.org
Cc: 7670 <at> debbugs.gnu.org
Subject: won't fix
Date: Sun, 22 Jul 2012 17:42:45 +0200

tags 7824 + wontfix
tags 7670 + wontfix
close 7824
close 7670
thanks

These bugs would IMHO be too expensive to fix, and anyway fixing them would
only bring a very marginal gain (as the issues only affects few vendor makes,
and only appears in unusual -- albeit admittedly fully legitimate -- setups).
In order not to keep the bug tracker cluttered up, I'm now closing these
reports, marking them as "wontfix".

Regards,
  Stefano

Message #43 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Юрий Пухальский
	<aikipooh <at> gmail.com>, 7824 <at> debbugs.gnu.org, 
	Automake List <automake <at> gnu.org>
Subject: Automatic chaining of make suffix rules (was: Re: bug#7824: won't fix)
Date: Mon, 23 Jul 2012 14:42:08 +0200

[Re-adding the list, as this discussion is worth being registered in
the archives IMHO]

On 07/23/2012 02:18 PM, Юрий Пухальский wrote:
> On Mon, Jul 23, 2012 at 3:40 PM, Stefano Lattarini
> <stefano.lattarini <at> gmail.com> wrote:
>> On 07/23/2012 11:42 AM, Юрий Пухальский wrote:
>>> I understand that it's about a year since last activity on that bug.
>>> And i had not yet time to write concisely about the issue i'm
>>> suffering from.
>>>
>>> The situation is that both of the approaches (.pc.c rule and .pc.lo
>>> rule) have problems entailed.
>>
>>>  * .pc.lo rule doesn't create tags for *.pc sources.
>>>
>> Try to add the relevant '.pc' files to $(TAGS_FILES) explicitly.  It should
>> solve your issue.  If it doesn't, you've found a new Automake bug, which I
>> will gladly fix :-)
>
> Ah, ok! I knew there must be something like that.
> But why in the first place it doesn't do it automatically? I have it
> in the _SOURCES… Is it afraid of the .pc extension?
>
I'm not sure actually.  Might be a tiny bug in automake.  Care to open a
new report about the issue, so I won't forget?  I'll get to it eventually,
but not right now.

>>
>>>  * .pc.c rule doesn't work on HP-UX.
>>>
>> Which is the "wontfix" bug unfortunately.  IMHO you should start lobbying
>> for the use of GNU make whenever possible, or you'll miss all the exciting
>> new features of Automake-NG ;-)
>
> "Und grün des Lebens goldner Baum…"
> 
> Alas! My thing must be highly portable. I'm not sure who's guilty in
> this case, maybe HP,
>
Well, their make is busted in another, more relevant way:

  <http://lists.gnu.org/archive/html/autoconf-patches/2011-01/msg00031.html>

And the INSTALL file from Automake itself reads:

   HP-UX `make' updates targets which have the same time stamps as
   their prerequisites, which makes it generally unusable when shipped
   generated files such as `configure' are involved.  Use GNU `make'
   instead.

This behaviour of HP-UX also violates the POSIX standard.

But back to your use case, the HP-UX issue at hand (not chaining suffix
rules automatically) is shared with at least another make implementation,
that is, Solaris XPG4 make.  But I usually don't care much about that
one, because Solaris users have other, much better make implementations
available from their vendor (that is, CCS make and Sun Distributed
make) which doesn't suffer from that limitation.  The *BSD makes don't
suffer from it either.  As for AIX, IRIX and OSF1/Tru64, I don't have
access to those systems, so I can't test how their make implementations
behave.

> but probably kicking austin group for clarification is not that
> bad idea.
>
It's a pretty good one indeed.  Especially if you are volunteering :-)

Thanks,
  Stefano

Message #46 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7824 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: Automatic chaining of make suffix rules (was: Re: bug#7824: won't
	fix)
Date: Mon, 23 Jul 2012 16:49:09 +0400

On Mon, Jul 23, 2012 at 4:42 PM, Stefano Lattarini
<stefano.lattarini <at> gmail.com> wrote:
> [Re-adding the list, as this discussion is worth being registered in
> the archives IMHO]
>
Ok.

>>>> The situation is that both of the approaches (.pc.c rule and .pc.lo
>>>> rule) have problems entailed.
>>>
>>>>  * .pc.lo rule doesn't create tags for *.pc sources.
>>>>
>>> Try to add the relevant '.pc' files to $(TAGS_FILES) explicitly.  It should
>>> solve your issue.  If it doesn't, you've found a new Automake bug, which I
>>> will gladly fix :-)
>>
>> Ah, ok! I knew there must be something like that.
>> But why in the first place it doesn't do it automatically? I have it
>> in the _SOURCES… Is it afraid of the .pc extension?
>>
> I'm not sure actually.  Might be a tiny bug in automake.  Care to open a
> new report about the issue, so I won't forget?  I'll get to it eventually,
> but not right now.
I'll doublecheck to be sure and will do.

>
>>>
>>>>  * .pc.c rule doesn't work on HP-UX.
>>>>
>>> Which is the "wontfix" bug unfortunately.  IMHO you should start lobbying
>>> for the use of GNU make whenever possible, or you'll miss all the exciting
>>> new features of Automake-NG ;-)
>>
>> "Und grün des Lebens goldner Baum…"
>>
>> Alas! My thing must be highly portable. I'm not sure who's guilty in
>> this case, maybe HP,
>>
> Well, their make is busted in another, more relevant way:
>
>   <http://lists.gnu.org/archive/html/autoconf-patches/2011-01/msg00031.html>
>
> And the INSTALL file from Automake itself reads:
>
>    HP-UX `make' updates targets which have the same time stamps as
>    their prerequisites, which makes it generally unusable when shipped
>    generated files such as `configure' are involved.  Use GNU `make'
>    instead.
>
> This behaviour of HP-UX also violates the POSIX standard.
>
> But back to your use case, the HP-UX issue at hand (not chaining suffix
> rules automatically) is shared with at least another make implementation,
> that is, Solaris XPG4 make.  But I usually don't care much about that
> one, because Solaris users have other, much better make implementations
> available from their vendor (that is, CCS make and Sun Distributed
> make) which doesn't suffer from that limitation.  The *BSD makes don't
> suffer from it either.  As for AIX, IRIX and OSF1/Tru64, I don't have
> access to those systems, so I can't test how their make implementations
> behave.
I have aix 5.3 and aix 6.1 here. So if you tell me how it's best to
check… As far as i remember i haven't had this very problem on AIX.

>
>> but probably kicking austin group for clarification is not that
>> bad idea.
>>
> It's a pretty good one indeed.  Especially if you are volunteering :-)
I've positive experience already. Ok, well, will put it to the list of
thing to do.

>
> Thanks,
>   Stefano



-- 
«Every person has a certain horizon. When it narrows and becomes
infinitely small, it changes into a point and then the person says:
“This is my point of view.”»

Message #49 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Юрий Пухальский <aikipooh <at> gmail.com>
Cc: 7824 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#7824: Automatic chaining of make suffix rules
Date: Mon, 23 Jul 2012 15:11:05 +0200

On 07/23/2012 02:49 PM, Юрий Пухальский wrote:
>
> [SNIP]
>
>>>
>>> Alas! My thing must be highly portable. I'm not sure who's guilty in
>>> this case, maybe HP,
>>>
>> Well, their make is busted in another, more relevant way:
>>
>>   <http://lists.gnu.org/archive/html/autoconf-patches/2011-01/msg00031.html>
>>
>> And the INSTALL file from Automake itself reads:
>>
>>    HP-UX `make' updates targets which have the same time stamps as
>>    their prerequisites, which makes it generally unusable when shipped
>>    generated files such as `configure' are involved.  Use GNU `make'
>>    instead.
>>
>> This behaviour of HP-UX also violates the POSIX standard.
>>
>> But back to your use case, the HP-UX issue at hand (not chaining suffix
>> rules automatically) is shared with at least another make implementation,
>> that is, Solaris XPG4 make.  But I usually don't care much about that
>> one, because Solaris users have other, much better make implementations
>> available from their vendor (that is, CCS make and Sun Distributed
>> make) which doesn't suffer from that limitation.
>>
Oops, I double checked, and It seems I got this wrong: Solaris CCS make
and Sun Distributed make do *not* support automatic chaining of suffix
rules in general :-/  They only support it if the intermediate target
appears as a dependency somewhere (which luckily is enough to make our
Lex/Yacc support -- which uses chains of suffix rules -- work correctly
with those makes; phfew!)

>> The *BSD makes don't
>> suffer from it either.  As for AIX, IRIX and OSF1/Tru64, I don't have
>> access to those systems, so I can't test how their make implementations
>> behave.
>
> I have aix 5.3 and aix 6.1 here. So if you tell me how it's best to
> check… 
>
You can use this Makefile:

  .SUFFIXES: .u .v .w
  .u.v: ; cp $< $@
  .v.w: ; cp $< $@

then "touch foo.u" and call "make foo.w".  If the file 'foo.w' is created
correctly, chaining of suffix rules is supported by the make implementation.

> As far as i remember i haven't had this very problem on AIX.
> 
>>> but probably kicking austin group for clarification is not that
>>> bad idea.
>>>
>> It's a pretty good one indeed.  Especially if you are volunteering :-)
>
> I've positive experience already. Ok, well, will put it to the list of
> thing to do.
> 

Thanks,
  Stefano

Message #52 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Юрий Пухальский <aikipooh <at> gmail.com>
To: Stefano Lattarini <stefano.lattarini <at> gmail.com>
Cc: 7824 <at> debbugs.gnu.org, Automake List <automake <at> gnu.org>
Subject: Re: bug#7824: Automatic chaining of make suffix rules
Date: Mon, 23 Jul 2012 17:31:40 +0400

>>> The *BSD makes don't
>>> suffer from it either.  As for AIX, IRIX and OSF1/Tru64, I don't have
>>> access to those systems, so I can't test how their make implementations
>>> behave.
>>
>> I have aix 5.3 and aix 6.1 here. So if you tell me how it's best to
>> check…
>>
> You can use this Makefile:
>
>   .SUFFIXES: .u .v .w
>   .u.v: ; cp $< $@
>   .v.w: ; cp $< $@
>
> then "touch foo.u" and call "make foo.w".  If the file 'foo.w' is created
> correctly, chaining of suffix rules is supported by the make implementation.

5.3:
bash-3.00$ touch foo.u
bash-3.00$ make foo.w
        cp foo.u foo.v
        cp foo.v foo.w
bash-3.00$ type make
make is hashed (/usr/bin/make)

(/usr/bin/make and /bin/make both link to /usr/ccs/bin/make)

6.1:
bash-3.00$ touch foo.u
bash-3.00$ /usr/ccs/bin/make foo.w
        cp foo.u foo.v
        cp foo.v foo.w

as we have got gmake installed in /usr/bin and /bin.

-- 
«Every person has a certain horizon. When it narrows and becomes
infinitely small, it changes into a point and then the person says:
“This is my point of view.”»

Message #59 received at 7824 <at> debbugs.gnu.org (full text, mbox):

From: Stefano Lattarini <stefano.lattarini <at> gmail.com>
To: Юрий Пухальский <aikipooh <at> gmail.com>
Cc: 7824 <at> debbugs.gnu.org
Subject: Re: bug#7824: Automatic chaining of make suffix rules
Date: Wed, 12 Sep 2012 21:30:31 +0200

On 09/12/2012 08:31 PM, Юрий Пухальский wrote:
> For your info, the proposed clarification in standard concerning chaining rules.
> http://austingroupbugs.net/view.php?id=602#c1363
>
Thanks for keeping me posted.  I'm sending this answer to the bug ticket
as well (in CC:), to give it some "closure" :-)

Regards,
  Stefano

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.