'make test-stem' yields No rule to make target '"./src/or/tor"'
Taking Nick's shiny new 0.2.8.1-alpha test tarball, and after building it, on Debian stable I get:
$/tmp/tor-0.2.8.1-alpha$ make test-stem
make: *** No rule to make target '"./src/or/tor"', needed by 'test-stem'. Stop.In the Makefile I see:
test-stem: need-stem-path $(TESTING_TOR_BINARY)where $TESTING_TOR_BINARY is
TESTING_TOR_BINARY = "$(top_builddir)/src/or/tor"I have a src/or/tor file just fine.
I don't know make language, so hopefully this is just an easy obvious fix.
Activity
changed milestone to %Tor: 0.2.9.x-final
added TorCoreTeam-postponed-201604 TorCoreTeam201605 component::core tor/tor milestone::Tor: 0.2.9.x-final owner::nickm points::0.4 priority::medium resolution::fixed reviewer::isis severity::normal sponsor::S-can status::closed tor-tests-integration tor-tests-stem type::defect version::tor 0.2.8.1-alpha labels
I didn't look very hard but it seems like the only 2 instances come from the following commit: https://gitweb.torproject.org/tor.git/commit/?id=670affa792e7613f6e6b5d960805418359ac0ec7
where some fellow cpunk apparently got m4/make/shell messed up in his head, and then nickm not testing what he applies. But hey it's an alpha, right? ...
Replying to cypherpunks:
I didn't look very hard but it seems like the only 2 instances come from the following commit: https://gitweb.torproject.org/tor.git/commit/?id=670affa792e7613f6e6b5d960805418359ac0ec7
where some fellow cpunk apparently got m4/make/shell messed up in his head, and then nickm not testing what he applies. But hey it's an alpha, right? ... This commit was added for #17818 (moved). The quotation of the make variables is indeed a mistake. Using
git grep "=\"" "*.am"only turned up instances of shell snippets within make rules except for those 2 instances. I propose the following patchdiff --git a/Makefile.am b/Makefile.am index fc9f7b2..62f7ef5 100644 --- a/Makefile.am +++ b/Makefile.am @@ -23,9 +23,9 @@ AM_CFLAGS = @TOR_SYSTEMD_CFLAGS@ SHELL = @SHELL@ if COVERAGE_ENABLED -TESTING_TOR_BINARY="$(top_builddir)/src/or/tor-cov" +TESTING_TOR_BINARY=src/or/tor-cov$(EXEEXT) else -TESTING_TOR_BINARY="$(top_builddir)/src/or/tor" +TESTING_TOR_BINARY=src/or/tor$(EXEEXT) endif include src/include.amThe
top_builddirvariable is not necessary because Tor only has one Makefile and according to the Autoconf documentation this variable is equal tobuilddir(which is always ".") in the top-level directory of the build tree. Furthermore, the Automake variableEXEEXTautomatically contains the appropriate executable extension for the platform. It is used internally by Automake to create its rules so in order to call the correct rule we have to add it too.The top_builddir variable is not necessary because Tor only has one Makefile and according to the Autoconf documentation this variable is equal to builddir (which is always ".") in the top-level directory of the build tree.
This happens to be the case now. The point is that the path is specified relative to the top level ("/src/or/tor"). So don't remove it, otherwise one would need to adjust it when/if the Makefile moves.
I can't comment about EXEEXT.
Replying to cypherpunks:
The top_builddir variable is not necessary because Tor only has one Makefile and according to the Autoconf documentation this variable is equal to builddir (which is always ".") in the top-level directory of the build tree.
This happens to be the case now. The point is that the path is specified relative to the top level ("/src/or/tor"). So don't remove it, otherwise one would need to adjust it when/if the Makefile moves. The Makefile is not going to move unless Tor moves back to recursive make (which is unlikely to happen, for the arguments see commit 2a4a1496241d6c4183763f90600be4775ccb5470). Iff that change happens the entire build configuration has to be rewritten because everything is currently specified relative to the top level (which can be seen in the include.am files). Additionally, the generated Makefile contains no rules that include the builddir for building the tor binary but it does contain the rule
src/or/tor$(EXEEXT): $(src_or_tor_OBJECTS) $(src_or_tor_DEPENDENCIES) $(EXTRA_src_or_tor_DEPENDENCIES) src/or/$(am__dirstamp)For these reasons i believe the builddir can safely be removed from the TESTING_TOR_BINARY variable. If there are instances where this would fail, i'm interested in hearing about them.
I can't comment about EXEEXT. If you're interested you can read more about it in the Automake documentation.
I think I'll retain the top_builddir, since it isn't actually hurting anything.
I needed to add some quotes and change some other stuff to make the dependencies make sense again.
Please have a look at branch
bug18240in my public repository?Trac:
Status: needs_review to assigned
Owner: N/A to nickmReplying to nickm:
Please have a look at branch
bug18240in my public repository? Making the test-network and test-network-all rules depend onTESTING_TOR_BINARYis redundant because they already depend on the all rule. Also these two rules actually need to depend on the all rule because they not only need the tor binary but also the tor-gencert binary.Be sure to update the changes file if you revert the changes on these two rules.
Replying to nickm:
Hm. Actually no, they should only depend on what they use.
Added a fixup commit. As with the
TESTING_TOR_BINARYchange, the tor-gencert dependency should includetop_builddirandEXEEXT.Note that this dependency currently only works because the test-network script does not use tor-cov-gencert binary when in coverage mode (see #18737 (moved)).
