Alan Apologies for top-posting (from my phone).
There is a potential snag in your approach which is that the build-projects wrapping of a project's own autotools/whatever is only as good as that project's build strategy. Good, relatively small projects are probably ok. I've read tales of woe and pages of "minor tweaks" trying to build Qt on Windows from source. If your build-projects wrapper fails that leaves the end-user with yet another layer to try to hack their way through. Anyway I wish you luck. We came to the conclusion years ago that the only reliable distribution was source built by the end-user only to discover that on a mac shipped binaries work well while on windows the contortions needed by a typical Windows user to install and build Qt/gcc application are excruciatingly painful. To my knowledge no one outside our team (3 of us!) has even attempted it. Linux on the other hand works best from source to adopt a consistent toolchain, most of which is bundled by the OS distributors. So we've gone the schizophrenic route. Binaries which work are great for executable applications. Building plugins or linking against libraries requires a working toolchain and build approach. Some of our mac users build binaries of plugins that they then ship to their friends who lack the toolchain, confidence, skills time or patience to compile source code. In chasing your build-project on the web I stumbled on mingw-builds which generates some external binaries. Actually only two: msys+friends and Qt. So I am going to try to build plplot (and our software) using their gcc 4.7.2 build of gcc and Qt4.8.4. Their documentation is non-existent and they don't tell me revision of 4.7.2 matches which of their Qt builds, but I've taken a good guess based on the date stamps. Since Qt 4.8.4 is the end of the Qt4 line, and gcc 4.7.2 reckoned to be a very good gcc, I'm hopeful that this will be a solid toolchain that is futureproof for a few years perhaps. I'll let you know how I get on in case you get driven in similar directions against your will or, as in my case, desperation. Best wishes Steve ----------- Steve Schwartz Space and Atmospheric Physics Imperial College London Tel 020 7594 7660 On 28 Jun 2013, at 03:35, "Alan W. Irwin" <[email protected]> wrote: > 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 ------------------------------------------------------------------------------ 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
