On Mon, Apr 13, 2009 at 4:56 PM, Mads Kiilerich <[email protected]> wrote: > Steve Borho wrote, On 04/13/2009 11:00 PM: >> >> sdist should only be needed for posix (non-win32) targets > > Fine for me, but even though tar-balls of releases might be _needed_ for > some target platforms only, I think it will serve you and the project well > if the release tar-balls contains everything for all platforms. That could > for example be usable for bootstrapping, for example if someone wants to > build an installer from source and a tool-chain they trust.
Building an installer on windows requires many repositories. The files under contrib\win32, for instance, are useless outside of the thg-installer forest. And the installer/ directory isn't used by anyone that I know of. Ugh. Ask me again after we have a sane build setup on Windows. >>> ReleaseNotes.txt >>> >> >> hmm, I wonder if this is necessary anymore. the release note >> wiki page is a better resource. >> > > Yes, but if it comes with the source then I would like to include it in an > rpm. True. I went ahead and added it to the manifest. > Another issue: setup.py imports shlib which imports gtk and thus requires a > gui at compile time: > > + python setup.py install -O1 --root > /home/mk/rpmbuild/BUILDROOT/tortoisehg-0.7.3.hg0fd37231b83d-1.fc11.i386 > --record=tortoisehg-all.files > abort: There is no Mercurial repository here (.hg not found) > Traceback (most recent call last): > File "setup.py", line 132, in <module> > from hggtk import shlib > File "/home/mk/rpmbuild/BUILD/tortoisehg-0fd37231b83d/hggtk/shlib.py", line > 14, in <module> > import gtk > File "/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 79, > in <module> > _init() > File "/usr/lib/python2.6/site-packages/gtk-2.0/gtk/__init__.py", line 67, > in _init > _gtk.init_check() > RuntimeError: could not open display > error: Bad exit status from /var/tmp/rpm-tmp.wzXWGJ (%install) Yep, that stinks. > But setup.py will always either be run from a repo with hg available OR from > a tar-ball. In either case a __version__.py wil always be available, so the > "unknown" magic is not relevant from setup.py, and __version__.py could thus > be imported directly by setup.py without any problems. That may be the least bad solution. I'll have to ponder on it for a bit. -- Steve Borho ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
