On 2015-04-18 10:23:07, DCOPPIT wrote:
Show quoted text> I missed one "g++" -> "c++" edit in the yagg script.
>
> > Another thing: on FreeBSD (and possibly also on other BSD systems) GNU
> make is available in /usr/local/bin/gmake. It would be nice if this could
> also be automatically detected.
>
> Unfortunately my module for finding progs doesn't know how to search for
> "gmake" and then fall back to "make". I could change the default prog name,
> but I'm not sure if gmake is more common than GNU make overriding any other
> make as /usr/local/bin/make...
My idea was to do something like this:
'make' => { default => ($^O eq 'freebsd' ? 'gmake' : 'make'), argname => 'MAKE',
On freebsd, "make" is always the BSD make which is not compatible with GNU make.
It's possible that netbsd and openbsd also need to be included into this condition, but I cannot verify it.
Show quoted text>
>
> On Wed, Apr 15, 2015 at 1:51 AM, Slaven_Rezic via RT <bug-yagg@rt.cpan.org>
> wrote:
>
> > Queue: yagg
> > Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=103515 >
> >
> > With this version "c++" is now prompted. However, run.t fails later:
> >
> > t/run.t ....... 1/4
> > # Failed test 'Encountered an error executing the test when one was not
> > expected.
> > # See /tmp/8PuTHCqJAl/run_infinite_loop.stdout and
> > # /tmp/8PuTHCqJAl/run_none.stderr.
> > #
> > # '
> > # at t/run.t line 86.
> > t/run.t ....... 3/4
> > # Failed test 'Encountered an error executing the test when one was not
> > expected.
> > # See /tmp/8PuTHCqJAl/run_left_recursion.stdout and
> > # /tmp/8PuTHCqJAl/run_none.stderr.
> > #
> > # '
> > # at t/run.t line 86.
> > # Looks like you failed 2 tests of 4.
> > t/run.t ....... Dubious, test returned 2 (wstat 512, 0x200)
> > Failed 2/4 subtests
> > (less 2 skipped subtests: 0 okay)
> >
> > Looking at the stderr files it seems that g++ is still used:
> >
> > gmake[1]: g++: Kommando nicht gefunden
> > gmake[1]: *** [build/generator/allocations/allocations_cache.o] Fehler 127
> > yagg: Compilation failed
> >
> > Another thing: on FreeBSD (and possibly also on other BSD systems) GNU
> > make is available in /usr/local/bin/gmake. It would be nice if this could
> > also be automatically detected.
> >
> > Regards,
> > Slaven
> >
> > On 2015-04-14 21:45:20, DCOPPIT wrote:
> > > Did you try entering "c++" when "perl Makefile.PL" prompts you for
> > > "g++"?
> > > It would probably complain (but continue) because it's not GNU g++. It
> > > checks for the GNU version explicitly.
> > >
> > > It's been ages, but my vague recollection is that there were some GNU-
> > > only
> > > aspects to the code. That said, I just tested with this:
> > >
> > > $ c++ --version
> > >
> > > Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
> > >
> > > Target: x86_64-apple-darwin14.1.0
> > >
> > > Thread model: posix
> > >
> > > and it worked fine. Note however that the makefile definitely uses GNU
> > > extensions.
> > >
> > > Care to try the attached? It includes the fix for the warning as well.
> > >
> > >
> > >
> > >
> > > On Tue, Apr 14, 2015 at 1:38 AM, Slaven_Rezic via RT <bug-
> > > yagg@rt.cpan.org>
> > > wrote:
> > >
> > > > Tue Apr 14 01:38:30 2015: Request 103515 was acted upon.
> > > > Transaction: Ticket created by SREZIC
> > > > Queue: yagg
> > > > Subject: Don't hardcode g++
> > > > Broken in: 1.4005
> > > > Severity: (no value)
> > > > Owner: Nobody
> > > > Requestors: SREZIC@cpan.org
> > > > Status: new
> > > > Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=103515 >
> > > >
> > > >
> > > > FreeBSD 10 does not ship g++ anymore, but instead clang++. yagg's
> > > > test
> > > > suite fails because "g++" is called in the process. Probably it's
> > > > better to
> > > > use "c++" instead, as this works on gcc and clang based systems.
> > > >
> > > >
> >
> >
> >
RT for rt.cpan.org