Experimenting with exemaker

[Didly]

On Tue, Mar 8, 2011 at 7:20 PM, Adrian Buehlmann <adrian at cadifra.com> wrote:

> On 2011-03-08 18:36, Didly wrote:
> > On Tue, Mar 8, 2011 at 4:58 PM, Steve Borho <steve at borho.org
> > <mailto:steve at borho.org>> wrote:
> >
> >     On Mon, Mar 7, 2011 at 10:39 PM, Matt Mackall <mpm at selenic.com
> >     <mailto:mpm at selenic.com>> wrote:
> >     > I've found a neat tool:
> >     >
> >     > http://effbot.org/zone/exemaker.htm
> >     >
> >     > Given an hg.py, this program makes a 4k hg.exe that:
> >     >
> >     > a) finds hg.py in the same directory as it's in
> >     > b) finds python.exe either in PATH or in the #! line in hg.py
> >     > c) finds python.dll wherever python.exe is
> >     > d) loads python.dll and launches hg.py
> >     >
> >     > In other words, it emulates the #! behavior of scripts on Windows.
> >     >
> >     > This has several advantages:
> >     >
> >     > - it gives you a hackable/patchable install
> >     > - extensions and hooks are more easily installed
> >     > - third party libraries are more easily added
> >     > - hgweb becomes easier to set up
> >     > - Python and hg are decoupled, so Python can be upgraded
> >     > - a lot of py2exe weirdness is avoided
> >     > - weirdness with command scripts calling command scripts is avoided
> >
> >     It 'avoids' py2exe weirdness by performing none of the work.  How is
> a
> >     package maintainer supposed to know which Python packages need to be
> >     included?  Or which DLLs are needed by all of the Mercurial source
> and
> >     extensions?
> >
> >     > The first item I think is a _really big deal_ as it'll make it much
> >     > easier for people to get involved in hacking Mercurial on Windows.
> >     This
> >     > is pretty urgently needed as that's where we have the most users
> >     and the
> >     > least developers.
> >
> >     Windows is not an O/S that supports hackable programs.  If we shipped
> >     source files in our installer and installed them under C:\Program
> >     Files\Mercurial it would lead to a maintenance nightmare.  If any
> user
> >     edits a .py file installed there, and they do not have write
> >     privileges in that folder, from Vista on-ward the O/S will save the
> >     file in a magical user-local folder and from that point onward that
> is
> >     the copy of the file the O/S reads from if the user ever opens the
> >     original file location.
> >
> >     This is why we put great big disclaimers on our hgrc files telling
> >     users not to edit them.  They will never (appear to) get upgraded if
> >     the user writes to them.
> >
> >     https://bitbucket.org/tortoisehg/stable/issue/135
> >
> >     And I'm ignoring the installer rewrite this would require, because
> >     that is something that is at least straightforward to resolve.
> >
> >     --
> >     Steve Borho
> >
> >
> > Steve,
> >
> > I don't know if this idea is suitable for deploying mercurial to regular
> > users, but perhaps it may be a great way to have a hackable distribution
> > that people can use if they want to try hacking on mercurial?
> >
> > For example, you may recall that a while ago I had problems running
> > tortoisehg from source because thg required me to have mercurial 1.8
> > source installed, but the mercurial source installer had not been
> > released yet. I then asked if it was possible for me to download the
> > mercurial repository and build it myself and if I recall correctly the
> > answer was that it was not simple to do. Granted, I could probably learn
> > how to do it but with the limited time I have every additional barrier
> > makes it less likely that I will bother even trying. I guess a lot of
> > people are in the same situation.
> >
> > If what Matt proposes would allow someone like me to have a source
> > mercurial installation that could be easily updated to follow the
> > mercurial repository it may be an improvement over the current
> situation...
>
> Angel (aka Didly),
>
> IIRC, last time you failed on the "compiling mercurial's C extensions"
> step. Or was that somebody else? Dunno.
>

Yes, that was basically it.


> Now, there is contrib/win32/buildlocal.bat. All that's needed is
> installing the correct version of the gratis Visual C++ express by
> Microsoft to get a C compiler (2008 for Python 2.6) and double-click
> that bat file to compile Mercurial's python C extensions in place.
>
> And of course you need to have python installed.
>

OK, that seems really simple. I will give it a try.


> Then it's handy to have a script to call the hg python script in the
> repo root. I have here a file hgc.cmd containing:
>
> @echo off
> set cmdpath=C:\Users\adi\hgrepos\hg-crew
> echo --- running hg from %cmdpath%
> C:\Python26_x64\python.exe "%cmdpath%\hg" %*
>
> This hgc.cmd is in a directory which is on my PATH ("hgc" for crew, I
> have another one, "hgm" for the main repo).
>
> Like that, I can type hgc in a cmd.exe terminal and run mercurial from
> source from my hg-crew clone on the command line.
>
>  $ hgc -q version
>  --- running hg from C:\Users\adi\hgrepos\hg-crew
>  Mercurial Distributed SCM (version 1.8+18-37f487b9fbcc)
>
> exemaker won't let you skip compiling the C extensions. Most people fail
> on that step already. And for developing, calling an xx.cmd will
> perfectly do. There's not much difference to have a hg.exe when developing.
>

OK, I was hoping that exemaker would allow me to skip that step.
Does this mean that everytime that you update to a different mercurial
revision, you need to recompile the C extensions?


> Running TortoiseHg from source is a different story which is slightly
> off topic here. But basically all you need is setting the HGPATH
> environment variable, let it point to a clone of hg with compiled C
> extensions in place.
>

Umm, I don't have that environment variable set. To run thg from source I
installed PyQT4, then used the mercurial installer in the thg-winbuild
downloads page and cloned the thg repo. Then I simply run
"C:\python26\python thg".



> I have a script "thgs.cmd" here, which contains:
>
> @echo off
> set HGPATH=C:\Users\adi\hgrepos\hg-main
> set cmdpath=C:\Users\adi\hgrepos\thg-qt
> echo --- running thg from %cmdpath%
> C:\python26_x64\python.exe "%cmdpath%\thg" %*
>
> With all other prerequisites installed (see [1], PyQt, pywin32), this
> will run the Qt TortoiseHg from source.
>
> I mostly run
>
>  $ thgs --nofork
>


> so I can see the output of python print statements, which I often insert
> into the python sources while hacking on something.
>
>
Thank you for the tip. I will use a script rather than directly calling
python as I was doing so far.

However while I wasn't using the --nofork option I still saw my print
statements. What does it really do?

One nice thing that I have discovered is that by using the --nofork option I
can now debug thg using the python debugger that is built into the editor
that I use (PyScripter), which great! Now I am able to put a breakpoint and
explore the methods and properties of the classes which I don't know about.
Cool! :-)

Thanks,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20110309/f8c0053b/attachment.htm>