can't build without darcs installed #257

Closed
opened 2008-01-04 23:04:38 +00:00 by zooko · 3 comments
zooko commented 2008-01-04 23:04:38 +00:00
Owner

Seb discovered that "make" fails if there is no darcs:

make make-version
python ./setup.py darcsver
darcsver is <module 'darcsver' from '/Users/wonwinmcbrootles/playground/allmydata/tahoe/trunk/darcsver-1.0.0-py2.5.egg/darcsver/__init__.pyc'>
running darcsver
error: No such file or directory
make[1]: *** [make-version] Error 1
make: *** [build] Error 2

We could make "make-version" pass in the case that darcs isn't present, but this spurred me to realize that we could also do something else: put the following into setup.py:

if 'darcsver' in not sys.argv: # to avoid recursion in case of weird sys.argv
    for arg in sys.argv:
        for start in ['bdist', 'build', 'sdist', 'install', 'develop']:
            if cmdname.startswith(start):
                (cin, cout, cerr,)= os.popen3("setup.py darcsver")
                print cout.read()

This would be similar to what we already did in setup.py back when "darcsver" was a separate script instead of a setuptools plugin, but it would be better, in that it would execute "darcsver" only in the case that the setup.py command being executed is one of those which wants a fresh version number.

Anyway, I guess that isn't directly related to this failure to build. The first thing to do is probably just configure the Makefile so that "make-version" failing doesn't cause builds to fail, if Brian agrees.

Seb discovered that "make" fails if there is no darcs: ``` make make-version python ./setup.py darcsver darcsver is <module 'darcsver' from '/Users/wonwinmcbrootles/playground/allmydata/tahoe/trunk/darcsver-1.0.0-py2.5.egg/darcsver/__init__.pyc'> running darcsver error: No such file or directory make[1]: *** [make-version] Error 1 make: *** [build] Error 2 ``` We could make "make-version" pass in the case that darcs isn't present, but this spurred me to realize that we could also do something else: put the following into setup.py: ``` if 'darcsver' in not sys.argv: # to avoid recursion in case of weird sys.argv for arg in sys.argv: for start in ['bdist', 'build', 'sdist', 'install', 'develop']: if cmdname.startswith(start): (cin, cout, cerr,)= os.popen3("setup.py darcsver") print cout.read() ``` This would be similar to what we already did in setup.py back when "darcsver" was a separate script instead of a setuptools plugin, but it would be better, in that it would execute "darcsver" only in the case that the setup.py command being executed is one of those which wants a fresh version number. Anyway, I guess that isn't directly related to this failure to build. The first thing to do is probably just configure the Makefile so that "make-version" failing doesn't cause builds to fail, if Brian agrees.
tahoe-lafs added the
packaging
major
defect
0.7.0
labels 2008-01-04 23:04:38 +00:00
tahoe-lafs added this to the 0.7.0 milestone 2008-01-04 23:04:38 +00:00
warner commented 2008-01-04 23:12:53 +00:00
Author
Owner

oh, I should change the Makefile to have build: depend upon src/allmydata/_version.py, and have src/allmydata/_version.py constructed with a rule that runs make-version. That ought to ensure that we run darcsver if there isn't already a _version.py (which should only ever be the case if we're building from a darcs checkout), and that we won't try to run it if there already is a _version.py (which should be the case if we're building from a tarball, and therefore don't require darcs to be available).

I'll give this a try.

oh, I should change the Makefile to have build: depend upon src/allmydata/_version.py, and have src/allmydata/_version.py constructed with a rule that runs make-version. That ought to ensure that we run darcsver if there isn't already a _version.py (which should only ever be the case if we're building from a darcs checkout), and that we won't try to run it if there already is a _version.py (which should be the case if we're building from a tarball, and therefore don't require darcs to be available). I'll give this a try.
warner commented 2008-01-05 05:14:48 +00:00
Author
Owner

I think that ought to have fixed it.. could you give it a try now?

I think that ought to have fixed it.. could you give it a try now?
zooko commented 2008-01-05 20:58:42 +00:00
Author
Owner

I tested it, and that fixes the build-without-darcs-but-with-_version.py scenario.

It is still the case that you have to run "make make-version" manually in order to refresh the version number. Moving my other idea into a separate ticket: #260 -- "automatic freshening of version number".

I tested it, and that fixes the build-without-darcs-but-with-_version.py scenario. It is still the case that you have to run "make make-version" manually in order to refresh the version number. Moving my other idea into a separate ticket: #260 -- "automatic freshening of version number".
tahoe-lafs added the
fixed
label 2008-01-05 20:58:42 +00:00
zooko closed this issue 2008-01-05 20:58:42 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: tahoe-lafs/trac-2024-07-25#257
No description provided.