On Sat, Oct 3, 2009 at 4:03 AM, Jonathan Marsden <jmars...@fastmail.fm> wrote: > > Jonathan Morgan wrote (after quoting my entire lengthy message): > > > In my opinon, the expected compiler to be used for Windows binaries is > > VC++, whether it is proprietary or not (for example, ask Mozilla, or > > OpenOffice, or Python). > > Expected by whom? Microsoft does not provide a compiler and linker with > its OS. There is no default C or C++ compilation environment on > Windows. Expected by commercial C/C++ developers who have never worked > on any other platform? Maybe. Is that a good thing? If so, why?
I would venture to guess that it's expected both by the commercial developers you mention and by the majority of people working on Windows who are programming on Windows as a hobby. Personally I've heard calls on this list for making our work more visible to Windows users and hopefully we'll be able to garner some more programmers due to the vast acceptance of Windows in the market. Many of my classmates when I was in school "expected" to be able to do their work in Windows with Visual C++, despite the fact that BSD, Linux and Solaris were all provided by the school, as was VC++, Borland and MinGW. Do we want more programmers from the Windows world to join in our efforts? If so, the all-free all-the-time goal that I hear shining through your statements in this email probably isn't a good way to encourage them. I'd love to see statistics, if anyone can find them, related to the number of developers who prefer to work with VS over the number who prefer to work with other build chains. I'd hang my hat on VS coming out significantly ahead of any others for desktop development. > > > I believe it is generally considered to produce better and more > > efficient code than MinGW (whether correctly or not, I cannot judge). > > Maybe -- as you said, you cannot judge, so that info shouldn't carry too > much weight, until it actually affects real world use of SWORD or one of > the SWORD-using applications. I submit that on current multi-GigaHertz > multi-core CPUs and multiple GigaBytes of RAM, differences of a few > percent in code optimization efficiency (whether space or speed) are > probably not critical to most desktop or laptop-wielding SWORD users. > If you have SWORD use cases on modern desktop of laptop machines where > such efficiency gains are indeed vital to successful SWORD deployment, > please share them, that would be interesting to know about. For > cellphones and similar smallish embedded platforms (some cellphones have > 64GB of storage these days... hardly small!), that kind of difference > might well be critical... but VC++ does not seem to target common > devices running Symbian, Android, whatever they call the Palm Pre OS, > etc. etc. at all. Wonderfully optimized compiled code that won't > execute on a given hardware platform or OS is not much help to users of > that platform. http://www.willus.com/ccomp_benchmark.shtml has some interesting benchmarks. Granted, it was last updated in 2007, he was using gcc 2.95 and VC 6. His conclusions are in line with other, more recent comparisons that I've seen. On his first benchmark note that: compile times in msvc are 3 TIMES as fast execution time averages across all the systems are 23% faster in msvc OK, so compile times aren't an enormous deal, but I'd say a 23% speed execution increase is. Also interesting, Borland was the only system to score slower than MinGW. On his fourth benchmark (skipping 2 and 3, since they are Fortran) again, MSVC comes in with approximately 3x the compilation speed but now the performance difference is negligible with MSVC very slightly ahead. All of those benchmarks were floating point, scientific computing based. In the Integer realm, again we see the same compile-time performance boost in MSVC but this time MinGW came in very slightly ahead in actual performance. http://keyj.s2000.ws/?p=86 contains more recent information with Visual Studio 2005, 2008, MinGW 4.3 and Intel's compiler 11.0. In all of his benchmarks it appears that VS and MinGW are closely tied in performance, with Intel's compilers kicking the pants off of both of them. It seems to boil down to his last paragraph, which seems to hold the biggest gem on his page: "The Intel compiler is nice, but it’s hard to use (Visual Studio integration doesn’t work with the Express Editions) and tends to generate bloated code, 50% larger than MSVC’s. The differences between MSVC and GCC are noticeable, but still not worth the hassle of using GCC on Win32 or being sad because of the unavailability of MSVC on Linux." Personally I use the commercial versions of Visual Studio, and I hear that Intel's compiler integrates marvelously well with it. Don't know I'd be willing to drop $600 on it, though. So really, it seems to boil down to: what are personal preferences. I, for one, like to use the "best tool for the job" without too much regard for whether or not it's proprietary or open source. Since Visual Studio has a very nice code editor and project editor, and because it is fairly ubiquitous whenever *I've* encountered people trying to build Windows programs, I'll personally stick with it. > > Further, VC++ has some obvious downsides, too. I can't fix VC++ if I > need to, and I can't apply whatever I do learn about it on other > platforms, either. Nor can you. I can't remember ever finding a hole in a compiler, let alone trying to fix it. This sounds like "high horse" mentality, and not a practical consideration for me. For you, perhaps it is, but definitely not for me and not for programmers who are used to working with a commercial compiler. > > For you, VC++ may be great. If you can form a little packaging team > that uses VC++ and then creates nice pretty easy Windows-style .MSI > installers for SWORD, and so take that specific load off the SWORD devs, > that would be great. Especially if you can do that so automated regular > builds and uploads of those to crosswire.org can happen. Then (after > more work!) repeat this for BibleTime and Xiphos, add more comprehensive > automated test suites for all of this, and we'll really have something > valuable, I suspect. > > Especially in the absence of such a team and such installers, I feel > that using skills and experience I already have, and using a toolchain > which is portable to or can target every general purpose OS I know of, > is *much* more worthwhile and of more interest, for me, doing this as an > unpaid volunteer, than spending my time learning details of a > proprietary toolchain for one proprietary OS. Incidentally, I suspect > that my "irrelevant" (ancient? archaic? obsolete?) knowledge of GCC and > autotools is quite likely to still be useful when VC++ is just a distant > memory :) > > Questions about "Windows doesn't seem to encourage compiling things, how > do I get started?" would suggest that there may in fact be room for > providing and documenting a reasonably straightforward way to do that > very thing, on Windows, using existing portable cross-platform open > source tools. Automating it, so others do not even have to do any SWORD > compiling for Windows themselves, seems an obvious and logical next > step. If you think there is also room for doing that kind of thing with > VC++, you may very well be 100% correct. If that is something which is > of interest to you, cool -- do it! If your results are clearly better > than anything I can come up with, then I'll almost certainly drop this > little side project at that point. With the exception of automating the system, since I have little interest in that, I've already built and documented building SWORD with VC++. Chris Little has also built it with VC++. I don't know if he's documented it or not, but this task has already been done. > > > BPBible uses VC++ to build Sword binaries to make it work with the > > standard Python distribution on Windows. > > IMO it's really sad that anyone would choose an open source > cross-platform language such as Python, on top of an open source > cross-platform library such as SWORD, and then deliberately restrict the > resulting application to just one OS. But it is your project, and so > entirely your choice. It's sad to me that you would want to foist the MinGW/MSYS system onto Windows and encourage potential developers in Windows to take one look at that, compare it in their minds against VC++, and say, "Nah, if I have to learn autotools and bash to get this done, never mind." Personally, if I wasn't already comfortable with Bash, I would certainly think that! I still do think it, because of the need to deal with autotools (I'd rather see a different system used which would allow a single, centralized set of build scripts instead of having to maintain the auto* and VC++ and BCB separately, but I'm in no position to complain about that, since I haven't volunteered to step up and create such a system). > > > Whether or not MinGW/autotools works is irrelevant, since it is not > > the expected development environment. > > You have now made repeated statements about "the expected" development > environment or software tool. However, you have provided no evidence > that the majority of volunteer C++ programmers in the SWORD-using world > prefer one development environment over the other. That a couple of > *very* large projects which started out commercial and later switcher to > open source use the Microsoft toolchain is not really relevant to SWORD, > which has been cross platform for many years now -- longer than either > Mozilla or OpenOffice I suspect! I don't think he's making the point that most SWORD programmers would "expect" it. I think he's pointing to most Windows developers would "expect" it. Yes, an equally unsubstantiated claim as your statements to the tune of GCC will be here when VC is a long-distant memory and your implicit claim that Windows programmers don't expect it. I'd like to see a study pointing one way or the other. I already said where my money is. > > More interestingly, if you take a "the Microsoft way is *the* expected > way" approach to toolchain choice on Windows, why would you choose > Python rather than a Microsoft-specific proprietary scripting language? > Surely on Windows, Python is not "the expected scripting language". > Perhaps VBscript or maybe Visual Basic or maybe C# is, on that basis. A > VBscript interpreter comes with every copy of a desktop or server > Microsoft OS since 2000, I think, so that surely is "the expected > scripting language" on that platform? :) Give me VBScript hooks to SWORD and maybe this point would be relevant. OK, so not myself, because I have no knowledge of programming in VBScript or knowledge of whether such an interface is possible. > > This has wandered a long way from the "poor cousins" starting point. > Let's return to those hypothetical cousins for a moment. Their poverty > relates to lack of SWORD binaries on their chosen OS. There seem to be > some in the Windows world who don't really care what development > environment is used, just so long as they can (if necessary compile and) > use the very latest SWORD code. I'm starting to work on something that > may eventually address that niche, and I'm documenting and publishing > what I have done so far, as I do it. If you have an alternative that > uses VC++ which you believe is superior, then please do publish it, and > please do set up regular automated SWORD builds (and corresponding > automated .MSI installer creation) for Windows with it -- perhaps *that* > could make what I am doing "irrelevant". As I said above -- already done. Anyone who wanted to could grab my description from the BibleTime development wiki and try to follow it to build the SWORD library. It's a little stale, but I last updated it after 1.6.0, so it's not that stale. VisualStudio comes with a built-in tool to make a VERY minimal .MSI installer. It also comes with an extremely extensive set of scripting tools and macros if you want to automate it. If SWORD's build utilities had a built-in packaging mechanism, that would already be taken care of (BibleTime's build system uses CMake which comes with CPack which will allow packaging to be automated on different systems. Currently it has code which works well on Mac OS X to build a drag-and-drop installer and works on Windows to build an NSIS based installer all within our one build system. autotools has no similar system that I'm aware of, and it is not used it for VC++ based builds of SWORD on Windows anyway.). OK, now that I've talked longer than I probably should have -- in short, the work has already been done to build SWORD with MSVC. It has already been built with MinGW/MSYS also by Matthew. Both produce code with comparable execution performance on Windows according to benchmarks I've seen. I'd venture to guess that we would have more people interested in building on Windows if they knew off-hand that the system builds out of the box with VS AND with MinGW, since we wouldn't have to push one on people who prefer the other. And yes, all of this seems to have grown out of a simple notice that BibleCS for 1.6.0 has not yet been released. Troy said he's hoping to fix that this weekend - I sincerely hope that he has the time. In the interim, people are more than welcome to check out Xiphos, BPBible or help me figure out why Qt4 seems to have great distaste for SVG files on Windows. --Greg _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page