Markus Wanner <mar...@bluegap.ch> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/monotone-devel