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 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. 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. 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. > 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. > 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! 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? :) 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". Jonathan _______________________________________________ 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
