Re: Mingw 64 bit build

Markus Wanner <[email protected]> writes:

> Stephen,
>
> On 05/04/2014 03:48 PM, Stephen Leake wrote:
>> Done in nvm.cleanup-warnings.
>
> Cool, thanks. I'll have another look, soon.
>
>> I think we should; there's nothing worse than trying to follow some
>> install instructions only to discover there is some crucial bit of
>> information missing.
>
> Yes, there is something worse than missing parts: Wrong parts. And
> out-dated stuff is pretty darn close to be wrong.

I disagree. The doc is accurate at a point in time; as long as that is
clear, people understand things change.

> The MinGW instructions prior to the recent release were helpful to some
> extent, but a lot of it was out-dated. I had to figure which parts still
> apply and which not. Granted, I didn't use the versions indicated in the
> doc. I wanted newer stuff. And I wish I had a more general, less verbose
> guide.

What would you suggest? I have no problem adding more stuff, but I
thought you wanted to reduce, not increase.

> Put another way: I just don't think we can keep up install instructions
> with that much detail for every of at least three different windoze
> build environments.

Well, I was only maintaining mingw. Now I've switched to maintaining
msys2-mingw2-32 and -64. If no one steps up to maintain the others, they
should be deleted.

>> For example, are the Botan args to configure necessary on Debian?
>
> Depends on which version of Botan you want to compile against. Maybe you
> even want to compile against a self-compiled one in a custom location.
> We cannot possible cover all variants - nor should we.

True. And the files don't claim to.

The point is to have one known working install, for people just getting
started on a new platform. Once they get that working, they can mess
around to build it differently.

>> I just
>> assume so (because they are required on cygwin and msys2), but I didn't
>> check. If I had not done the msys2 install first, I would not have known
>> to use them, and would have wasted time figuring that out for Debian.
>
> Configure tells you pretty clearly if it found what it needs or what's
> missing, if it didn't. 

Yes, but it does _not_ tell you how to fix it. Why would I imagine that
I should add "-I/usr/include/botan-1.10", when aptitude confirms that I
installed the botan devel package?

> Reading through pages of outdated options on how
> I don't want to do it would certainly waste much more time for me,
> thanks.

In the debian case, and in msys2, it is not "pages of outdated options".
MinGW was worse, but it's obsolete now.

>> On the other hand, a large part of INSTALL_windows_msys2_64.txt talks
>> about how to install msys2. That sort of instruction is not required for
>> Debian and other Linux distros,
>
> Huh? If that needs explanation, please go help the mingw or msys2
> project. 

I tried that; they are not interested. I find that many open source
projects are not interested in good docs; apparently it's less fun than
code. git is _much_ worse than monotone; it's one of the many things I
like about monotone.

> The monotone source tree clearly is the wrong place to put that
> documentation, as most users in need for it won't find it, there.

I agree that non-monotone msys2 users won't find it there. 

As a work-around until the msys2 project improves their docs, this makes
the most sense to me.

>> Notice that a significant portion of the messages we've exchanged are
>> about "what tools are you using?". Having identical tool setups is
>> essential to tracking down bugs.
>
> I don't think we're in the position to enforce a tool chain on your
> users. 

I'm not "enforcing" anything; merely documenting one known configuration
that does work.

> The best we can do is make monotone easy to compile on most
> platforms.

Yes. And "easy" means "here are all the options I had to sweat to figure
out, so you don't have to".

I agree that doesn't help if the doc is significantly out of date (as
mingw was). I don't see how a less specific doc can be _more_ helpful.

> Instead of a lengthy document, 

100 lines is _not_ "lengthy".

If you want a _lengthy_ tools install document, see
http://gds.gsfc.nasa.gov/tools_install_linux_developer.pdf (32 pages).
That's what I use for work. I would be utterly lost without it. 

> why not bundle the entire set of tools required to build monotone in a
> zip file ready to delpoy?

Because that most likely won't work as time goes by. The install docs
give enough information to catch up to new versions when necessary.

> That would save the tedious work of accurately following 100 lines of
> boring instructions.

If someone can't follow 100 lines of boring instructions to get a working
system, they are not likely to be much help to the monotone project.

Unless we do provide a tools installer, the same amount of tedious work
has to be done anyway; I don't see how it would be better to have to
also figure out each step along the way. I guess it could be more fun,
but I'd rather save my brain power for the project, not waste it on the
tools.

>> I don't understand the rationale for moving stuff to the wiki. That's
>> harder to edit, and it won't be kept up to date. 
>
> Wikis hard to edit? 

Yes; editing a wiki is harder than editing a text file on my local disk,
in the same directory as the rest of monotone.

And yes, the wiki/browser GUI interface is much harder to use than
Emacs. 

>Do we use the same Internet?

The internet has many faces; we probably use quite disjoint sets.

> To me, the existing instructions felt more like a protocol of your
> experience getting monotone to compile from source on Windows. 

Yes, that's what it is. It doesn't claim to be anything else.

That's exactly what I look for when I need to compile a new project on a
new platform.

-- 
-- Stephe