digitalmars.D.learn - Thrift maintained..?
- simendsjo (14/14) Nov 15 2013 I thrid compiling thrift 0.9.1 from github with d support, but
- David Eagen (5/19) Dec 21 2013 I ran into this same problem but haven't had time to look into
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (7/21) Dec 21 2013 addprefix is a make function:
- Martin Nowak (3/17) Dec 21 2013 Rebuild autoconf and automake files?
- David Eagen (9/11) Dec 25 2013 That's what actually breaks it. I was messing around on another
- David Eagen (12/14) Feb 11 2014 So the Thrift guys are not too excited about fixing this. The bug
- David Eagen (4/7) Feb 11 2014 I should have pointed out that using the serial-tests option with
- simendsjo (3/9) Feb 11 2014 Well, that seems quite unprofessional.. Not fixing bugs that
- David Eagen (8/10) Feb 12 2014 To be fair he wasn't able to reproduce the problem. It built fine
I thrid compiling thrift 0.9.1 from github with d support, but
there's a bug in the makefile it seems.
$(addprefix.log: $(addprefix
p='$(addprefix'; \
b='$(addprefix'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
"$$tst" $(AM_TESTS_FD_REDIRECT)
The error is reported at the first line with the message:
Makefile:1206: *** unterminated variable reference. Stop.
Can anyone spot the error? (And preferably send a pull request so
I don't take the credit :) )
Nov 15 2013
"David Eagen" <davideagen mailinator.com>
On Friday, 15 November 2013 at 21:11:36 UTC, simendsjo wrote:
I thrid compiling thrift 0.9.1 from github with d support, but
there's a bug in the makefile it seems.
$(addprefix.log: $(addprefix
p='$(addprefix'; \
b='$(addprefix'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
"$$tst" $(AM_TESTS_FD_REDIRECT)
The error is reported at the first line with the message:
Makefile:1206: *** unterminated variable reference. Stop.
Can anyone spot the error? (And preferably send a pull request
so I don't take the credit :) )
I ran into this same problem but haven't had time to look into
what is required to fix it. We need someone more familiar with
make to figure it out.
I imagine the problem is related to the unbalanced parens.
Dec 21 2013
On 11/15/2013 01:11 PM, simendsjo wrote:
I thrid compiling thrift 0.9.1 from github with d support, but there's a
bug in the makefile it seems.
$(addprefix.log: $(addprefix
p='$(addprefix'; \
b='$(addprefix'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
"$$tst" $(AM_TESTS_FD_REDIRECT)
The error is reported at the first line with the message:
Makefile:1206: *** unterminated variable reference. Stop.
Can anyone spot the error? (And preferably send a pull request so I
don't take the credit :) )
addprefix is a make function:
http://www.gnu.org/software/make/manual/html_node/File-Name-Functions.html
$(addprefix prefix,names...)
None of the addprefix calls in that excerpt look correct. :-/
Ali
Dec 21 2013
On Friday, 15 November 2013 at 21:11:36 UTC, simendsjo wrote:
I thrid compiling thrift 0.9.1 from github with d support, but
there's a bug in the makefile it seems.
$(addprefix.log: $(addprefix
p='$(addprefix'; \
b='$(addprefix'; \
$(am__check_pre) $(LOG_DRIVER) --test-name "$$f" \
--log-file $$b.log --trs-file $$b.trs \
$(am__common_driver_flags) $(AM_LOG_DRIVER_FLAGS)
$(LOG_DRIVER_FLAGS) -- $(LOG_COMPILE) \
"$$tst" $(AM_TESTS_FD_REDIRECT)
The error is reported at the first line with the message:
Makefile:1206: *** unterminated variable reference. Stop.
Can anyone spot the error? (And preferably send a pull request
so I don't take the credit :) )
Rebuild autoconf and automake files?
Try ./bootstrap.sh && ./configure && make.
Dec 21 2013
On Saturday, 21 December 2013 at 19:20:44 UTC, Martin Nowak wrote:Rebuild autoconf and automake files? Try ./bootstrap.sh && ./configure && make.That's what actually breaks it. I was messing around on another box where Thrift compiled just fine and found my configure script was not calling ./bootstrap.sh first so it was using old Makefiles. Unfortunately I don't know how long ago I ran bootsrap.sh on that box so I don't know what version broke the Makefile generation. I've filed a bug: https://issues.apache.org/jira/browse/THRIFT-2294
Dec 25 2013
On Wednesday, 25 December 2013 at 17:14:17 UTC, David Eagen wrote:I've filed a bug: https://issues.apache.org/jira/browse/THRIFT-2294So the Thrift guys are not too excited about fixing this. The bug was closed since it affected just the D library. I think the problem stems from the fact that I have automake 1.13 which uses the parallel test harness by default. You can convert back to the serial test harness by setting this in configure.ac: AM_INIT_AUTOMAKE([1.11 tar-ustar serial-tests]) The serial test harness is the default for automake 1.12 and earlier. There must be a reason the D library's Makefile is screwed up when the parallel test harness is used but so far I haven't found it.
Feb 11 2014
On Wednesday, 12 February 2014 at 02:27:51 UTC, David Eagen wrote:You can convert back to the serial test harness by setting this in configure.ac: AM_INIT_AUTOMAKE([1.11 tar-ustar serial-tests])I should have pointed out that using the serial-tests option with automake 1.13 results in a correct D Makefile and a successful thrift build.
Feb 11 2014
On Wednesday, 12 February 2014 at 02:27:51 UTC, David Eagen wrote:On Wednesday, 25 December 2013 at 17:14:17 UTC, David Eagen wrote:Well, that seems quite unprofessional.. Not fixing bugs that makes parts of their repository unusable..I've filed a bug: https://issues.apache.org/jira/browse/THRIFT-2294So the Thrift guys are not too excited about fixing this. The bug was closed since it affected just the D library.
Feb 11 2014
On Wednesday, 12 February 2014 at 07:53:44 UTC, simendsjo wrote:Well, that seems quite unprofessional.. Not fixing bugs that makes parts of their repository unusable..To be fair he wasn't able to reproduce the problem. It built fine on his box. They list automake 1.9 as the requirement so presumably he isn't running 1.13 and that's why he didn't run into it. I'm hoping to fix it in 1.13 in a way that also works for earlier versions of automake. If I can I'll reopen an contribute a patch. Now if I can just figure out how automake works....
Feb 12 2014