On Wed, Apr 29, 2015 at 02:54:59PM -0700, Jon A. Cruz wrote:
Yes, so did we get the info on dependencies/versions updated?
One of our main pages: http://wiki.inkscape.org/wiki/index.php/Tracking_Dependencies
That probably also needs to have OS X 10.6 explicitly called out. It currently is limited to gcc 4.2.1. And for all that Macs out there with hardware limitations, updating the OS and/or compiler is not an option.
I know there are pre-Intel mac (PPC?) hardware which can run no newer version of the OS simply because of Apple. Supposedly there is a healthy secondary market for this obsoleted hardware, which artists frequent. Presumably getting newer Illustrator on this platform is problematic, thus presenting a value proposition Inkscape can fill.
Yet, providing this legacy compatibility is not without some cost. We're hearing from multiple sources about the impact of these costs; at the moment it's holding back progress with modernizing our code syntax.
This happens to include my main laptop :-)
As a secondary factor, we probably need fill in more detail on our wiki page for C++11 http://wiki.inkscape.org/wiki/index.php/C%2B%2B11
I know for a fact that some of the "supported" features on earlier compilers are *not* quite there, and require explicit work-arounds for portable code. There aren't too many of those, but just enough that we will need to track them ourselves and not count on some of the externally referenced pages on C++11 support.
Well, a plan we worked out at the hackfest I think will suitably address this.
Alex will be introducing a test binary, sort of a canary-in-the-coal-mine, in which we can put examples of various C++-11 features, and hook it up in the build system. Then as folks build Inkscape on various platforms if they run into problems with that they can tell us, and we simply disable that feature in the canary. We'd also of course provide a switch or setting to bypass the canary so folks with problems can still easily get inkscape built. This should give ample time for you and other users of legacy hardware a chance to test the support.
Then, if we do a successful release with no complaints, developers will be free to start introducing the given feature in the mainline codebase.
We can follow this strategy through to the 1.0 release. Since this should be an especially stable release, we can make that a long term supported release for the 10.6 users and other legacy cases. And then post-1.0 we can take a more aggressive jump forward in dependencies like C++-11.