On 2013-06-27 15:05-0700 phil rosenberg wrote: > One question though. If a binary version is built with gcc, can it be used by > Visual Studio or vica-versa?
In general, I think the answer is no. It is best to build everything needed with a consistent tool chain. > If PLPlot wants to increase its windows use then it shouldn't alienate VS users (and I'm one of them) because their compiler is free (like free beer), but not free (like freedom). Point taken, but note binary distributors would also not want to alienate the huge numbers of MinGW users as well. MinGW-4.7.2 has been averaging 20,000 downloads of its core package per month for the 7 months since its release. And MinGW-4.6.2 has had 800 thousand (!) downloads of its core package since its release. (You can find these numbers yourself by exploring http://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/. You will actually find much larger numbers there at first blush, but if you dig for the download numbers of just the core package in each case you will find what I have stated above.) You do make a good point that the choice of tool chain is an additional concern for binary releases. In principle we could supply both forms. But then somebody would complain about the MinGW version or cl version being used that was too old or too new for their needs, and suddenly satisfying everybody's tool chain needs turns into a big headache. Linux distributions handle this issue by stating up-front what tool chain version they are using, and forcing everybody who uses that binary release to use the same tool chain. I notice also for Windows binary releases (e.g., Qt4) that they are typically for only one tool chain (in the Qt4 case an old version of MinGW that is not suitable for my needs). So whoever is willing to take responsibility for a binary release will probably have to make a decision about which tool chain to use for that release rather than trying to cater to everybody's needs with multiple binary distributions. Note, thinking about the inherent and well known issues of binary distributions at this stage is getting rather far ahead of ourselves. Instead, for the immediate future we should be concentrating on the build-script idea (where ideally every user builds what he likes with the tool chain that he desires). That is, along with everything else I have planned for build_packages, we should make build_packages as general as possible with regard to the tool chain that the user wants to build with. In fact, as far as I know there are only a few parts of build_projects that currently depend on gcc. For example, a special gcc option is supplied to wxwidgets to get it to build with gcc on Windows. But that CMake logic can easily be protected by if(CMAKE_COMPILER_IS_GNUCC) ... endif(CMAKE_COMPILER_IS_GNUCC) The fundamental point is that the CMake EXTERNAL_PROJECT_Add command (which is what is used in */bp.cmake to configure and build each project) is inherently quite general. All that is needed is a command to download the source code and check it, a command to configure the project (e.g., cmake or autotools or anything else), a command to build the project (make, mingw32-make, jom, ninja, etc.), a command to install the project (typically a special form of one of the build commands), and a command to test the project (typically a special form of one of the build commands or ctest). That's it (which is the reason the */bp.cmake files are so small). Therefore, Phil, when I am in a better position to call for testing of build_projects, I would certainly welcome your testing of it with any tool chain you desire and would welcome your patches for any problems you discover for your tool chain of choice. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Plplot-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
