Opened 7 years ago

Closed 5 years ago

#1688 closed bug (worksforme)

build broken on Debian

Reported by: daniel.santos Owned by:
Milestone: 3.5.0 Keywords:


OK, so this computer started out as Debian Mint and was later converted to debian (mostly), so I don't realy trust it all too much. However, I noticed a few practices that I consider bad.

First off, you guys are including config.{guess,sub}, which I personally never do, but I'm not an autotools guru (or a guru in any build system for that matter). So I tried 3.5.0-dev and 3.4.0 and multiple different options passed to configure, but I kept getting this once it had build most of the c sources:

No rule to make target @MAINFILES@', needed by angband'. Stop

So I did a little test and determined that MAINFILES was never being defined or populated. I finally took a big hammer to it and fixed the problem, but I don't know which action did the trick, so here's my list:

First, I thought maybe there's something old from when I built it last year:
rm -rf install-sh configure config.* autom4te.cache/ mk m6
rm -rf m4 mk run-tests scripts/ utils/
git reset --hard

Next, I thought these pre-packaged autotools scripts could be the cause:
rm config.*
automake --add-missing
# of course, I missed install-sh, but oh well

Finally, I modified and ran it again:
-run_or_die $ACLOCAL -I m4
-run_or_die $AUTOHEADER
-run_or_die $AUTOCONF
+run_or_die $ACLOCAL -I m4 --force
+run_or_die $AUTOHEADER --force
+run_or_die $AUTOCONF --force

So one of these fixed it, I'm not sure which sorry about that part.

Change History (6)

comment:1 Changed 7 years ago by magnate

Er, MAINFILES is definitely defined and populated, and builds fine on all my Debian systems. Can you list the commands you're typing to get the errors (from a fresh checkout or untar of pristine source), and I'll try to help.

I have a horrible suspicion that this is because we refuse to ship and ship configure instead.

comment:2 Changed 7 years ago by daniel.santos

OK, so I reproduced part of the problem (but not the full one, I'll do some more experimentation). This could be because I had a different version of autotools installed when I built 3.3 last year.

$ git clone --reference ${HOME}/proj/angband git:// angband-test
$ cd angband-test
$ git reset --hard v3.3.0
$ ./
$ ./configure
$ make
$ git reset --hard origin
$ make clean
Makefile:2: mk/ No such file or directory
make: *** No rule to make target `mk/'.  Stop.

$ ./configure
$ make clean
Makefile:2: mk/ No such file or directory
make: *** No rule to make target `mk/'.  Stop.

$ ./
$ ./configure
$ make clean
-- this works

However, when I was originally trying to build it, it didn't work, I had to do a lot of different things to get it to work, so I'll see if I can cook up more precisely what happened. However, something should be making sure that mk/*.mk files are regenerated or maybe deleted when configure or distclean is run? I'm not sure.

comment:3 Changed 6 years ago by takkaria

  • Milestone changed from Triage to 3.5.0

Assigning open bugs to 3.5 for fixing.

comment:4 Changed 6 years ago by magnate

I think you can safely close this for 3.5 - building is definitely not broken on Debian, and the OP has not updated for a long while.

comment:5 Changed 6 years ago by daniel.santos

Yeah, go ahead. Sorry I never got back around to trying to reproduce it. I ended up putting gentoo on my laptop. Maybe somebody else will run into the problem and re-open or file a new bug. IIRC, the problem appeared to be after updating my local repo after a year or so and then attempting to clean & build -- some .mk files weren't being regenerated.

If it helps at all, I've experienced similar problems on at least one or two other projects as well.

Last edited 6 years ago by daniel.santos (previous) (diff)

comment:6 Changed 5 years ago by myshkin

  • Resolution set to worksforme
  • Status changed from new to closed

Closing as worksforme per the comments above.

Note: See TracTickets for help on using tickets.