This fixes the remaining out-of-tree issues:
make deploy was brokenmake distcheck now passes, and Travis has been switched to an out-of-tree build for dogfooding purposes. Fingers-crossed that it works.
Don't glob the leveldb for dist. That means we need to enumerate the headers.
- clear the __pycache__ during 'make clean'
- Copy the qrc locale file to a temp location and remove it when finished
(rcc expects everything to be in the same path)
- Link pull-tester/rpc-tests.py to the build dir
- Add the build-dir's config to the python path so that tests can find it
- The tests themselves are in srcdir
- Clean up __pycache__ in 'make clean'
The plist is generated, lives in builddir.
37 | @@ -37,7 +38,7 @@ 38 | # terminal via ANSI escape sequences: 39 | BOLD = ('\033[0m', '\033[1m') 40 | 41 | -RPC_TESTS_DIR = BUILDDIR + '/qa/rpc-tests/' 42 | +RPC_TESTS_DIR = SRCDIR + '/qa/rpc-tests/'
Note to myself: Does the cache (from create_cache.py et al.) end up in SRCDIR now?
Wasn't it always (and still is) the case that the cache ends up in the current directory when the tests are launched?
Correct.
Though, this should be changed. Having different caches lying around in folders that happen to be your working dir right then is misleading at best.
Anyway, this is unrelated to this pull.
I'm having a hard time answering that question because of the symlink interaction with Python. builddir/rpc-tests.py is now a symlink to sourcedir/rpc-tests.py because it needs to be writable. But that makes the definition of "current dir" hazy. @MarcoFalke I suppose it would be best to make the location explicit.
Sure, this is on my list of cleanups. If no one beats me to it, you can expect it some time after feature freeze. ;)
Concept ACK
Generally speaking, if it's used as-is from git, it's srcdir. If it's generated or pre-processed, it's builddir.
Put another way: after checkout, think of srcdir as read-only. If anything is modified, it must happen in builddir.
utACK 142ffc7
make check fails with:
Running test/bitcoin-util-test.py...
Traceback (most recent call last):
File "../../src/test/bitcoin-util-test.py", line 8, in <module>
import buildenv
ImportError: bad magic number in 'buildenv': b'\x03\xf3\r\n'
@MarcoFalke Yes, I just saw that as well while trying to answer the question above. I'm not sure why Travis passes.
I'll fix that one up.
Pushed a quick fix for @MarcoFalke's problem. I'm not sure if we really need that or not, but it's probably better than each dev running into the problem and googling for themselves.
The issue is this: previous invocations of python2 in an in-tree build would leave a buildenv.pyc hanging around in srcdir. We prepend python's search path with builddir, but for some reason it ends up finding the srcdir/buildenv.pyc (and missing .py) before the builddir/buildenv.py. python3 refuses to load the old python2 .pyc, and errors because it can't find a .py at the same path for recompilation.
With python3, pyc's are organized into a pycache dir, and tagged like: pycache/buildenv.cpython-35.pyc. So it should not be possible to hit this case anymore.
This was caused by an pyc files hanging around from previous
python2 invocations, when the matching .py missing from that path.
This should not be a problem with python3's tagged caches.
Tested ACK 340012d
28 | @@ -29,6 +29,7 @@ 29 | import tempfile 30 | import re 31 | 32 | +sys.path.append("qa/pull-tester/")
Is it safe to assume everyone runs the tests from the root of buildir?
Probably not, but FWIW at least I do...
I do too.
Heh, I run them from qa/pull-tester. I had no idea you could run them from the root...
Not sure how to fix this...
What about byte-compiling the rpc-tests.py instead of linking?
Heh, I run them from qa/pull-tester. I had no idea you could run them from the root...
Same here. But running from the root is ok with me.
Extensively-tested, with the following results:
I built, make check'd, and confirmed the reported version numbers for:
Note that:
Observations:
BTW seems make translate also needs changes to work out-of-tree. Not necessarily in this pull.
Looks like this is enough:
diff --git a/src/Makefile.qt.include b/src/Makefile.qt.include
index 3b39919..327a3d1 100644
--- a/src/Makefile.qt.include
+++ b/src/Makefile.qt.include
@@ -390,13 +390,13 @@ QT_QM=$(QT_TS:.ts=.qm)
SECONDARY: $(QT_QM)
-qt/bitcoinstrings.cpp: $(libbitcoin_server_a_SOURCES) $(libbitcoin_wallet_a_SOURCES)
+$(srcdir)/qt/bitcoinstrings.cpp: $(libbitcoin_server_a_SOURCES) $(libbitcoin_wallet_a_SOURCES) [@test](/github-metadata-backup-bitcoin-bitcoin/contributor/test/) -n $(XGETTEXT) || echo "xgettext is required for updating translations"
$(AM_V_GEN) cd $(srcdir); XGETTEXT=$(XGETTEXT) PACKAGE_NAME="$(PACKAGE_NAME)" COPYRIGHT_HOLDERS="$(COPYRIGHT_HOLDERS)" COPYRIGHT_HOLDERS_SUBSTITUTION="$(COPYRIGHT_HOLDERS_SUBSTITUTION)" $(PYTHON) ../share/qt/extract_strings_qt.py $^
-translate: qt/bitcoinstrings.cpp $(QT_FORMS_UI) $(QT_FORMS_UI) $(BITCOIN_QT_CPP) $(BITCOIN_QT_H) $(BITCOIN_MM)
+translate: $(srcdir)/qt/bitcoinstrings.cpp $(QT_FORMS_UI) $(QT_FORMS_UI) $(BITCOIN_QT_CPP) $(BITCOIN_QT_H) $(BITCOIN_MM) [@test](/github-metadata-backup-bitcoin-bitcoin/contributor/test/) -n $(LUPDATE) || echo "lupdate is required for updating translations"
- $(AM_V_GEN) QT_SELECT=$(QT_SELECT) $(LUPDATE) $^ -locations relative -no-obsolete -ts qt/locale/bitcoin_en.ts
+ $(AM_V_GEN) QT_SELECT=$(QT_SELECT) $(LUPDATE) $^ -locations relative -no-obsolete -ts $(srcdir)/qt/locale/bitcoin_en.ts
$(QT_QRC_LOCALE_CPP): $(QT_QRC_LOCALE) $(QT_QM) [@test](/github-metadata-backup-bitcoin-bitcoin/contributor/test/) -f $(RCC)
Updated: bitcoin_en.ts was written to the build directory instead of the source directory, now fixed.
Also available at: https://github.com/laanwj/bitcoin/tree/2016_06_translate_out_of_tree
Let's try to get this merged soon.
I can PR the make translate change separately if that's mroe convenient.
@luke-jr I believe I've found the issue here. When you "chown -R root:root .", you're setting the git index to read-only. That makes "git diff" fail to update the index, which makes the diff-index fail.
For the sake of this PR, I'm ok with that not working correctly, since git is in a pretty bad state.
since git is in a pretty bad state
That sounds ominous. Time to switch to mercurial or bzr? :-)
Haha. That was a half-complete thought as usual.
Should read: "I'm ok with that not working correctly, since if you're hitting this case, your git repo is already unreliable".
Milestone
0.13.0