"No rule to make target `unix/unix.o'" error when compiling prepatched r73 tarball.

[GoogleCodeExporter]

What steps will reproduce the problem?
1. ./configure
2. make
3. wait

I'm on 64-bit Gentoo (mostly stable but with a few unstable packages) and
I've tried compiling the prepatched sources from the r73 tarball in a
variety of ways but I always end up with a "No rule to make target
`unix/unix.o'" error.

I initially encountered this problem with r27 but I was too busy to
experiment and I only just found time now. The only versions I've tried
have been r27 and r73.

If I enable OpenGL, it complains while trying to make osnes9x and if I
disable it, it complains while trying to make snes9x. The presence or
absence of --with-gtk has no apparent effect. I'm attaching a full log from
'./configure && make'

Original issue reported on code.google.com by stephan....@gmail.com on 7 Jun 2009 at 9:46

Attachments:

• build.log

[GoogleCodeExporter]

Are you compiling from within the gtk subdirectory?

Original comment by tsukuyom...@gmail.com on 8 Jun 2009 at 4:13

[GoogleCodeExporter]

No, and doing so makes it work, but it's a usability nightmare.

I guess the new bug title is "Root Makefile neither succeeds nor prints an
explanatory error message guiding users to the gtk subdirectory". After all,
requiring that users build from inside a subdirectory runs counter to every
expectation of how Linux/*nix compilation works.

Autotools, scons, cmake, qmake, setup.py, etc... The one constant is that they 
all
teach users to act from root of the tarball... it doesn't help that the vast 
majority
of users learn by experience that reading INSTALL is a waste of time once you 
know
"./configure && make && sudo make install". It doesn't help that, if you've got 
a
root Makefile/Sconstruct/etc., people like me can re-read the docs as closely 
as they
want without noticing something like "change into the gtk subdirectory first".

Original comment by stephan....@gmail.com on 8 Jun 2009 at 8:47

[GoogleCodeExporter]

I'm aware this may be problematic. The question here is "how invasive should the
patch be." I will certainly add a replacement configure with an error message 
to the
full prepatched tarball to tell the user to switch to the gtk directory, 
considering
it doesn't include the other ports. I'm not going to replace the original build
system yet, though.

Original comment by bear...@gmail.com on 11 Jun 2009 at 10:56

• Changed state: Accepted

[GoogleCodeExporter]

This should be resolved in revision 74. The full tarball replacement configure 
script
indicates the directory should be changed first. I imagine those using the 
patch read
enough of the instructions that it shouldn't be necessary there.

Original comment by bear...@gmail.com on 3 Jul 2009 at 6:19

• Changed state: Fixed

[GoogleCodeExporter]

Hopefully. I thought I'd read it thoroughly but the habitual expectation of how
buildsystems are laid out caused me to miss the note about the second configure
script in /gtk. (In other words, the people more likely to use the patch are 
more
likely to make this mistake because they're probably more used to the typical 
routine)

Original comment by stephan....@gmail.com on 4 Jul 2009 at 5:46