Experimenting with exemaker

[Adrian Buehlmann]

On 2011-03-09 13:18, Didly wrote:
> 
> On Tue, Mar 8, 2011 at 7:20 PM, Adrian Buehlmann <adrian at cadifra.com
> 
>     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.

No. exemaker doesn't compile C sources.

> Does this mean that everytime that you update to a different mercurial
> revision, you need to recompile the C extensions?

In theory, yes.

If the C sources (mercurial/*.c) were changed, then definitely. But in practice,
that happens rarely.

For mercurial 1.8 the C extensions were indeed changed. So, before the 1.8 release,
that meant recompiling the C extensions when switching from default to stable branch
(and vice versa).

>     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".

You might have a "global" mercurial source-install lurking inside python's
site packages folder (e.g. in C:\Python26\Lib\site-packages).

Try renaming the C:\Python26\Lib\site-packages\mercurial folder and see if you
still can run thg from source.

I think running 'python setup.py build' followed by 'python setup.py install'
in the repo root of a mercurial clone will install mercurial there.

I believe if you don't set HGPATH, running thg from source will pickup
the mercurial installed in site-packages, which is a royal PITA, since using a
compiled mercurial "in place" (i.e. with having "in place" compiled C
extensions) from a normal clone of the mercurial source repo allows you to
follow mercurial's main repo updates. The stable branch of thg now follows
the stable branch of the mercurial main repo (http://selenic.com/repo/hg)

Official builds of thg are always made using the stable branch of the
mercurial main repo.

BTW, the next step for you is to learn doing msi builds yourself!
Clone https://bitbucket.org/tortoisehg/thg-winbuild and read the
README.txt file there, then execute 'python setup.py' and see what
options there are. I currently use "python setup.py --thg-stable". This
will place the msi in the output folder (if all goes well). I suggest you
follow-up on the thg-dev mailing list if you have questions about that.

The goal is that people are empowered to build their stuff themselves.
At least we need more guys who can do that. To increase the bus factor.

http://en.wikipedia.org/wiki/Bus_factor

>     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?

It doesn't fork a new cmd.exe but will instead use the cmd.exe you are in
right then. Observe what the terminal prompt does with and without --nofork
and see how many cmd.exe you have in the "Windows Task Manager".

You're probably right about the print statements. I thought there were some
stdout or stderr things which weren't emitted. Maybe some kinds of tracebacks
(but this has now much improved in thg 2.0 due to the immediate traceback
window popping up).

> 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! :-)

See. I can learn from you as well! I didn't know about PyScripter. I'll
probably give it a shot. Thanks for the hint.