Re: [Monotone-devel] mingw-instructions

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On 01/08/2011 06:19 PM, Stephen Leake wrote:
>
>> Correct. But it would be nice to document how the executables on our
>> download page are built. In fact, that's a requirement of the GPL 3
>> license
>
> Some of our downloads like the Windows installer bundle the libraries we
> use. So for any copyleft libraries, we really ought to actually host the
> source for the version used.

I believe the actual requirements of GPL 2
(http://www.gnu.org/licenses/gpl-2.0.txt, item 3) are that the source be
available, and that we tell people how to get it. So I think the current
INSTALL_windows_native.txt is ok in that regard.
 
>> (which we should upgrade to).
>
> Eww.

Can you elaborate? GPL 3 is technically more sophisticated than GPL 2. 

I don't think the process of upgrading requires getting approval from
all current authors, because our license statements say "GPL 2 or greater".
But I'm not a lawyer, so maybe that doesn't mean we get to change it to
"GPL 3 or greater".

>>> What we can see here is also that installation instructions are never
>>> really complete nor 100% perfectly working, 
>> 
>> Well, I was striving to meet that requirement for the MinGW
>> instructions. I agree the others are not.
>
> The current instructions are actually old enough to be broken, in that
> for example the appropriate SQLite file is named differently now and the
> listed versions of some MinGW files are in different places.

Sigh. Thanks for pointing this out. MinGW is a moving target.

On the other hand, INSTALL_windows_native.txt does correspond to the
state of my machine. But as you point out, that doesn't mean they can be
used to reproduce that state.

So either we need to 

a) update to the latest MinGW for each release

b) accept that we can't be fully precise in this area. 

I don't want to commit to a), so I'll settle for b).

>>> so a general disclaimer like the one you stated above might be the way
>>> to go (or even something more general like "we tested this with
>>> release so-and-so last time, everything might have changed in the
>>> meantime").
>> 
>> Ok, I've left that milestone in 1.0 in RoadMap.
>
> Speaking of which, does anyone know why a monotone built with the new
> instructions might eat several seconds of CPU time before entering
> main(), 

ouch!

It's probably some library initialization; maybe reading all the
internationalization files? But that should be the same on Linux.

Maybe some library is interacting with the Windows Registry?

> or how I might debug that (especially given that ^C under gdb
> apparently kills gdb instead of breaking)?

I'm not aware of an 'strace' function for MinGW, but maybe there is one.


In the meantime, I'll keep my current MinGW setup, so I can build a
useful executable :). 

If I have time, I'll try to install the latest MinGW in a parallel
setup, so I can also test it.

-- 
-- Stephe