Bugzilla Bug 147725

Hello, I use GCC 4.1.1 and xmoto-0.2.1 fails if I compile it with
MAKEOPTS="-j2" or higher, I must use MAKEOPTS="-j1" or it fails to build

Making all in extra
make[1]: Entering directory
`/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1/extra'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1/extra'
make[1]: Entering directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1'
make[1]: Nothing to be done for `all-am'.
make[1]: Leaving directory `/var/tmp/portage/xmoto-0.2.1/work/xmoto-0.2.1'

!!! ERROR: games-sports/xmoto-0.2.1 failed.
Call stack:
  ebuild.sh, line 1546:   Called dyn_compile
  ebuild.sh, line 937:   Called src_compile
  ebuild.sh, line 1255:   Called games_src_compile
  games.eclass, line 136:   Called die

!!! emake failed
!!! If you need support, post the topmost build error, and the call stack if
relevant.

Created an attachment (id=97080) [edit]
xmoto-0.2.1.ebuild - Forces MAKEOPTS="-j1"

Created an attachment (id=97081) [edit]
xmoto-0.2.1.diff

I confirm this problem and the solution, on x86 (athlon-xp) with gcc-3.4.5-r1
(old, I know). Here's the required patch.

That's not the solution, just a workaround.

(In reply to comment #3)
> That's not the solution, just a workaround.

Yup. A workaround which fixes a problem. Something which fixes a problem is a
solution. You don't just keep the problem going until you've come up with the
*perfect* "solution", because that's stupid, when there are reasonable measures
in-between. Are you saying that this solution is reasonable or unreasonable?

ebuilds aren't to touch MAKEOPTS

(In reply to comment #4)
> (In reply to comment #3)
> > That's not the solution, just a workaround.
> 
> Yup. A workaround which fixes a problem. Something which fixes a problem is a
> solution. You don't just keep the problem going until you've come up with the
> *perfect* "solution", because that's stupid, when there are reasonable measures
> in-between. Are you saying that this solution is reasonable or unreasonable?

I'm saying workarounds avoid problems not fix them.

(In reply to comment #5)
> ebuilds aren't to touch MAKEOPTS

There's lots that *do* "touch MAKEOPTS", from my quick grep query. Should I
raise a separate bug with a list of them? Is it better to use "emake -j1" in
the ebuild? Thanks for explaining *nothing*.

If you could provide a *reason*, then that would help people like me (who want
to contribute, and *have* contributed) a hell of a lot to understand what on
Earth is going on here. Rather than just stating facts as if they are obvious,
when they are totally non-obvious.

sorry, I had parallel make disabled and did not notice this while bumping :(

I have worked around it with emake -j1. This of course is no solution. The
solution is to patch the makefiles so that they properly work in parallel.

no idea either why makeopts is evil, mr_bones? Will see what I can do about the
makefiles now.

upstream moved the xmoto target to the subdir but still wants the result in the
top directory. But the rule here is broken

xmoto: src/xmoto
       ln -sf src/xmoto xmoto

make: *** No rule to make target `src/xmoto'.  Stop.

but cd src; make xmoto works. Since I do not know another way to do it I will
probably ask upstream to revert the change. Any better ideas?

(From update of attachment 97081 [edit])
because other package maintainers do such garbage is no excuse

at any rate; fix the package properly, dont be lazy and force -j1

(In reply to comment #10)
> fix the package properly

Yeah, great. Until the "ideal" fix, are you going to ignore the "pragmatic" fix
of "-j1", for some strange reason of idealism over reality?

(In reply to comment #11)
> (In reply to comment #10)
> > fix the package properly
> 
> Yeah, great. Until the "ideal" fix, are you going to ignore the "pragmatic" fix
> of "-j1", for some strange reason of idealism over reality?
> 

"I have worked around it with emake -j1."

workarounds have a tendency to become permanent fixes

fix it once; dont work around it many times

I mailed upstream about this. They are informed of the issue. Will keep you
updated.

no longer fails in 0.2.4