Summary: We are considering adopting new cleaner & more flexible C++ language features. This may not work with some older compiler versions. Opinions are warmly welcomed! -----
Hi All,
At the Hackfest, we discussed adopting features from the C++11 standard into our code. The advantages are (among others) significantly cleaner, more flexible and more readable syntax. I've included three examples at the end of this message.
Our discussion included consideration of users of older compilers. A convenient summary of compiler support is available at [1]. Several features (illustrated in the examples below) are well supported, including range-based for loops, type inference and variadic templates.
If we adopt these three specific features, we will require:
GCC >= 4.6 Clang >= 3.1 (or another suitable compiler!)
A complete migration to C++11 would require:
GCC >= 4.8.1 Clang >= 3.3
I propose that we adopt C++11 on a feature-by-feature basis, with discussion before requiring any bump in compiler version. We can track this in the wiki or similar.
We could potentially consider introducing a couple of the "safer" features within the next release cycle. Maybe even in time for 0.92?!
I will be pushing some demos of C++11 features to the branch lp:inkscape/~valavanisalex/inkscape/cpp11-port [2] for testing by other devs/testers before we consider merging anything into trunk. I will let you know when anything interesting is there!
We're very interested in any opinions or comments! Will this migration affect you? Is it good for the project? Do you see any trouble ahead?
Best wishes,
Alex
[1] http://en.cppreference.com/w/cpp/compiler_support [2] https://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
(Examples follow)
== 1. Type inference ==
The compiler can automatically determine the type of variables, based on the return type of functions etc. For example:
std::vector<std::pair<Glib::ustring, Glib::ustring> > pairs = ColorProfile::getProfileFilesWithNames();
becomes...
auto pairs = ColorProfile::getProfileFilesWithNames();
== 2. Range-based for-loops ==
Often, we just want to iterate over the entire contents of a container. The syntax is much cleaner in C++11:
for(std::vectorInkscape::SnapCandidatePoint::iterator i = _all_snap_sources_sorted.begin(); i != _all_snap_sources_sorted.end(); ++i){ // whatever }
becomes...
for(auto &i : _all_snap_sources_sorted){ // whatever }
== 3. Variadic templates ==
Sometimes we want many variants on the same function that take a different number of arguments. For example:
template <typename CurveType, typename A> void appendNew(A a) { // whatever }
template <typename CurveType, typename A, typename B> void appendNew(A a, B b) { // whatever }
<snip />
template <typename CurveType, typename A, typename B, typename C, typename D, typename E, typename F, typename G, typename H, typename I> void appendNew(A a, B b, C c, D d, E e, F f, G g, H h, I i) { // whatever }
This long (and incomplete) set of functions can be replaced by a single variadic template in C++11:
template <typename CurveType, typename... Args> void appendNew(Args... args) { // whatever }
On Tue, Apr 28, 2015 at 04:05:10PM +0100, Alex Valavanis wrote:
Summary: We are considering adopting new cleaner & more flexible C++ language features. This may not work with some older compiler versions. Opinions are warmly welcomed!
Hi All,
At the Hackfest, we discussed adopting features from the C++11 standard into our code. The advantages are (among others) significantly cleaner, more flexible and more readable syntax. I've included three examples at the end of this message.
Our discussion included consideration of users of older compilers. A convenient summary of compiler support is available at [1]. Several features (illustrated in the examples below) are well supported, including range-based for loops, type inference and variadic templates.
If we adopt these three specific features, we will require:
GCC >= 4.6 Clang >= 3.1 (or another suitable compiler!)
A complete migration to C++11 would require:
GCC >= 4.8.1 Clang >= 3.3
I propose that we adopt C++11 on a feature-by-feature basis, with discussion before requiring any bump in compiler version. We can track this in the wiki or similar.
We could potentially consider introducing a couple of the "safer" features within the next release cycle. Maybe even in time for 0.92?!
I will be pushing some demos of C++11 features to the branch lp:inkscape/~valavanisalex/inkscape/cpp11-port [2] for testing by other devs/testers before we consider merging anything into trunk. I will let you know when anything interesting is there!
We're very interested in any opinions or comments! Will this migration affect you? Is it good for the project? Do you see any trouble ahead?
Thanks for writing up this summary of our discussion Alex!
I've also updated the roadmap to reflect some of our discussions, although I may have made it a bit more conservative than you'd like... please take a look and see what you think.
Essentially, I think we should put the new feature into the test program, and ship with that for at least one release before turning folks loose using it in the mainline codebase. But then once 1.0 hits I figure we can be a lot more aggressive about upping our C++-11 requirements.
Bryce
Alex
[1] http://en.cppreference.com/w/cpp/compiler_support [2] https://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
(Examples follow)
== 1. Type inference ==
The compiler can automatically determine the type of variables, based on the return type of functions etc. For example:
std::vector<std::pair<Glib::ustring, Glib::ustring> > pairs = ColorProfile::getProfileFilesWithNames();
becomes...
auto pairs = ColorProfile::getProfileFilesWithNames();
== 2. Range-based for-loops ==
Often, we just want to iterate over the entire contents of a container. The syntax is much cleaner in C++11:
for(std::vectorInkscape::SnapCandidatePoint::iterator i = _all_snap_sources_sorted.begin(); i != _all_snap_sources_sorted.end(); ++i){ // whatever }
becomes...
for(auto &i : _all_snap_sources_sorted){ // whatever }
== 3. Variadic templates ==
Sometimes we want many variants on the same function that take a different number of arguments. For example:
template <typename CurveType, typename A> void appendNew(A a) { // whatever }
template <typename CurveType, typename A, typename B> void appendNew(A a, B b) { // whatever }
<snip />
template <typename CurveType, typename A, typename B, typename C, typename D, typename E, typename F, typename G, typename H, typename I> void appendNew(A a, B b, C c, D d, E e, F f, G g, H h, I i) { // whatever }
This long (and incomplete) set of functions can be replaced by a single variadic template in C++11:
template <typename CurveType, typename... Args> void appendNew(Args... args) { // whatever }
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Tue, Apr 28, 2015 at 04:05:10PM +0100, Alex Valavanis wrote:
== 2. Range-based for-loops ==
Often, we just want to iterate over the entire contents of a container. The syntax is much cleaner in C++11:
for(std::vectorInkscape::SnapCandidatePoint::iterator i = _all_snap_sources_sorted.begin(); i != _all_snap_sources_sorted.end(); ++i){ // whatever }
becomes...
for(auto &i : _all_snap_sources_sorted){ // whatever }
Some of Inkscape's loops (very few) modify the container that is looped over. In that case, the two are not equivalent. IIRC,
for (auto &i : container)
is syntactic sugar for something like:
for (container::iterator i = begin(container), e = end(container); i != e; ++i)
Note that end(container) is evaluated only once, instead of on every iteration. (Independent of C++11, if you write a new loop, in my opinion it's better to use this notation instead of "i != end(container)".)
A loop like this: for (...container...) { ... container.push_back(blah); ... } will do something different with ranged-for notation. Regardless, such a loop is pretty confusing for most and should be rewritten anyway. I remember a bug involving one such loop, perhaps it was the only one in the program.
-Johan
On Tue, Apr 28, 2015, at 08:05 AM, Alex Valavanis wrote:
Summary: We are considering adopting new cleaner & more flexible C++ language features. This may not work with some older compiler versions. Opinions are warmly welcomed!
Hi All,
At the Hackfest, we discussed adopting features from the C++11 standard into our code. The advantages are (among others) significantly cleaner, more flexible and more readable syntax. I've included three examples at the end of this message.
Our discussion included consideration of users of older compilers. A convenient summary of compiler support is available at [1]. Several features (illustrated in the examples below) are well supported, including range-based for loops, type inference and variadic templates.
If we adopt these three specific features, we will require:
GCC >= 4.6 Clang >= 3.1 (or another suitable compiler!)
A complete migration to C++11 would require:
GCC >= 4.8.1 Clang >= 3.3
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.
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.
OK, thanks for the feedback. Is Clang available on OS X 10.6? I have no idea about OS X development... can you point me to a resource for figuring out the available software versions on a given release? I'll take a look at updating the dependency tracker accordingly.
Best wishes,
Alex
On 29 April 2015 at 22:54, Jon A. Cruz <jon@...18...> wrote:
On Tue, Apr 28, 2015, at 08:05 AM, Alex Valavanis wrote:
Summary: We are considering adopting new cleaner & more flexible C++ language features. This may not work with some older compiler versions. Opinions are warmly welcomed!
Hi All,
At the Hackfest, we discussed adopting features from the C++11 standard into our code. The advantages are (among others) significantly cleaner, more flexible and more readable syntax. I've included three examples at the end of this message.
Our discussion included consideration of users of older compilers. A convenient summary of compiler support is available at [1]. Several features (illustrated in the examples below) are well supported, including range-based for loops, type inference and variadic templates.
If we adopt these three specific features, we will require:
GCC >= 4.6 Clang >= 3.1 (or another suitable compiler!)
A complete migration to C++11 would require:
GCC >= 4.8.1 Clang >= 3.3
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.
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.
-- Jon A. Cruz jon@...18...
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
Bryce
El jue, 30-04-2015 a las 22:15 -0700, Bryce Harrington escribió:
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.
Sure I'm biased, but wouldn't it be reasonable to consider only the FLOSS operating systems for legacy support?
For instance, I just Debian Jessie, and it's available for PowerPC. That means that the old hardware you describe is supported by at least one free operating system, where Inkscape can be executed.
It seems unreasonable that the inkscape project has to constrain itself because of the decisions of a company who decided to stop supporting its own hardware, its own operating system. If it was Apple's decision, they would probably prefer that those machines end in a dumpster, so the option is keep using them with an old an unsupported operating system that no longer provides a good user experience, or switching to a modern operating system.
So why Inkscape development has to be constrained by the decisions taken by Apple regarding their products? You're not abandoning users if you move on (as Apple certainly did), they still have options to get the current version of inkscape running.
Gez.
They also can put another SO on his machines. 100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000points El vie, 01-05-2015 a las 19:11 -0300, Gez escribió:
El jue, 30-04-2015 a las 22:15 -0700, Bryce Harrington escribió:
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.
Sure I'm biased, but wouldn't it be reasonable to consider only the FLOSS operating systems for legacy support?
For instance, I just Debian Jessie, and it's available for PowerPC. That means that the old hardware you describe is supported by at least one free operating system, where Inkscape can be executed.
It seems unreasonable that the inkscape project has to constrain itself because of the decisions of a company who decided to stop supporting its own hardware, its own operating system. If it was Apple's decision, they would probably prefer that those machines end in a dumpster, so the option is keep using them with an old an unsupported operating system that no longer provides a good user experience, or switching to a modern operating system.
So why Inkscape development has to be constrained by the decisions taken by Apple regarding their products? You're not abandoning users if you move on (as Apple certainly did), they still have options to get the current version of inkscape running.
Gez.
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, May 01, 2015 at 07:11:03PM -0300, Gez wrote:
El jue, 30-04-2015 a las 22:15 -0700, Bryce Harrington escribió:
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.
Sure I'm biased, but wouldn't it be reasonable to consider only the FLOSS operating systems for legacy support?
It's reasonable, if you don't own the hardware in question. :-)
Trust me, in an ideal world I'd even like to see Inkscape supported on FLOSS o/s's only for non-legacy support. I'm very much a free software zealot in that respect. But that would probably cut off 90% of our users, and a number of our developers. We live in the world we live in.
My rule of thumb is this - if we have active developers with an *interest* in supporting a given platform, then that is a signal the platform is sufficiently non-obscure that we should seriously consider supporting it. And in this case, Jon and su_v fulfil that rule for me, which is why I support sticking with it, at least up through 1.0.
Bryce
For instance, I just Debian Jessie, and it's available for PowerPC. That means that the old hardware you describe is supported by at least one free operating system, where Inkscape can be executed.
It seems unreasonable that the inkscape project has to constrain itself because of the decisions of a company who decided to stop supporting its own hardware, its own operating system. If it was Apple's decision, they would probably prefer that those machines end in a dumpster, so the option is keep using them with an old an unsupported operating system that no longer provides a good user experience, or switching to a modern operating system.
So why Inkscape development has to be constrained by the decisions taken by Apple regarding their products? You're not abandoning users if you move on (as Apple certainly did), they still have options to get the current version of inkscape running.
Gez.
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Fri, 2015-05-01 at 15:56 -0700, Bryce Harrington wrote:
On Fri, May 01, 2015 at 07:11:03PM -0300, Gez wrote: It's reasonable, if you don't own the hardware in question. :-)
Trust me, in an ideal world I'd even like to see Inkscape supported on FLOSS o/s's only for non-legacy support. I'm very much a free software zealot in that respect. But that would probably cut off 90% of our users, and a number of our developers. We live in the world we live in.
My rule of thumb is similar, in that it requires both developers who are able to support it and the required resources from users to underwrite it if it starts to effect lots of other developers. If it's true that 90% of our users are legacy proprietary platforms, then asking them to kick in a bit of time and money to offset the pain of dealing with the restrictions would be reasonable.
But honestly, I think a lot of our users are on fairly easy targets (windows XP/7). Mac being the hardest because of it's extreme depreciation of some of our core pieces.
But the Free Software activist side of me thinks it's a worthwhile investment if we can introduce a way to educate users about their platforms and why a Free Software platform would be better for future buying decisions.
Martin Owens,
My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Thanks,
AV
On 2 May 2015 at 00:06, Martin Owens <doctormo@...400...> wrote:
On Fri, 2015-05-01 at 15:56 -0700, Bryce Harrington wrote:
On Fri, May 01, 2015 at 07:11:03PM -0300, Gez wrote: It's reasonable, if you don't own the hardware in question. :-)
Trust me, in an ideal world I'd even like to see Inkscape supported on FLOSS o/s's only for non-legacy support. I'm very much a free software zealot in that respect. But that would probably cut off 90% of our users, and a number of our developers. We live in the world we live in.
My rule of thumb is similar, in that it requires both developers who are able to support it and the required resources from users to underwrite it if it starts to effect lots of other developers. If it's true that 90% of our users are legacy proprietary platforms, then asking them to kick in a bit of time and money to offset the pain of dealing with the restrictions would be reasonable.
But honestly, I think a lot of our users are on fairly easy targets (windows XP/7). Mac being the hardest because of it's extreme depreciation of some of our core pieces.
But the Free Software activist side of me thinks it's a worthwhile investment if we can introduce a way to educate users about their platforms and why a Free Software platform would be better for future buying decisions.
Martin Owens,
One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-05-02 01:39 (+0200), Alex Valavanis wrote:
My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Mac OS X 10.7.5, Xcode 4.3.2:
1) i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
checking build system type... x86_64-apple-darwin11.4.2 checking host system type... x86_64-apple-darwin11.4.2 checking for a BSD-compatible install... /Volumes/magenta/mp-trunk/quartz/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /Volumes/magenta/mp-trunk/quartz/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking for style of include used by make... GNU checking for gcc... llvm-gcc-4.2 checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether llvm-gcc-4.2 accepts -g... yes checking for llvm-gcc-4.2 option to accept ISO C89... none needed checking whether llvm-gcc-4.2 understands -c and -o together... yes checking dependency style of llvm-gcc-4.2... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking whether we are using the GNU C++ compiler... yes checking whether llvm-g++-4.2 accepts -g... yes checking dependency style of llvm-g++-4.2... gcc3 checking whether llvm-g++-4.2 supports C++11 features by default... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++0x... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
2) Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
checking build system type... x86_64-apple-darwin11.4.2 checking host system type... x86_64-apple-darwin11.4.2 checking for a BSD-compatible install... /Volumes/magenta/mp-trunk/quartz/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /Volumes/magenta/mp-trunk/quartz/bin/gmkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking how to create a pax tar archive... gnutar checking for style of include used by make... GNU checking for gcc... /usr/bin/clang checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/clang accepts -g... yes checking for /usr/bin/clang option to accept ISO C89... none needed checking whether /usr/bin/clang understands -c and -o together... yes checking dependency style of /usr/bin/clang... gcc3 checking for ar... ar checking the archiver (ar) interface... ar checking whether we are using the GNU C++ compiler... yes checking whether /usr/bin/clang++ accepts -g... yes checking dependency style of /usr/bin/clang++... gcc3 checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++0x... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
On 2015-05-02 02:04 (+0200), su_v wrote:
On 2015-05-02 01:39 (+0200), Alex Valavanis wrote:
My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Mac OS X 10.7.5, Xcode 4.3.2:
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
checking whether llvm-g++-4.2 supports C++11 features by default... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++0x... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
- Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++0x... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
After upgrading to Xcode 4.6.3 (latest Xcode release for OS X 10.7.5):
3) $ clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Default configure output ($CXX is /usr/bin/clang++):
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... yes
If configure is run with "-std=c++11 -stdlib=libstdc++" added to CXXFLAGS:
checking whether /usr/bin/clang++ supports C++11 features by default... yes
It appears that this specific AX macro detects C++11 support with the newer clang version shipped with Xcode 4.6.3, but I don't know how that would work out if Inkscape actually used them freely (C++ runtime is still libstdc++ from GCC 4.2.1, in either case). Any chance for more fine-grained tests, based on specific C++11 features?
Regards, V
On 2015-08-25 09:16 (+0200), su_v wrote:
On 2015-05-02 02:04 (+0200), su_v wrote:
On 2015-05-02 01:39 (+0200), Alex Valavanis wrote:
My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Mac OS X 10.7.5, Xcode 4.3.2:
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
checking whether llvm-g++-4.2 supports C++11 features by default... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++0x... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
- Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++0x... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
After upgrading to Xcode 4.6.3 (latest Xcode release for OS X 10.7.5):
- $ clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Default configure output ($CXX is /usr/bin/clang++):
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... yes
If configure is run with "-std=c++11 -stdlib=libstdc++" added to CXXFLAGS:
checking whether /usr/bin/clang++ supports C++11 features by default... yes
It appears that this specific AX macro detects C++11 support with the newer clang version shipped with Xcode 4.6.3, but I don't know how that would work out if Inkscape actually used them freely (C++ runtime is still libstdc++ from GCC 4.2.1, in either case). Any chance for more fine-grained tests, based on specific C++11 features?
IIUC Cmake 3.3.x runs internal compiler tests for supported c++98 and C++11 features - the C++11-related snippet from ${cmake_build_dir}/CMakeFiles/CMakeOutput.log is attached.
Again - I'm uncertain what to make of this...
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
AV
On 25 August 2015 at 08:46, su_v <suv@...2204...> wrote:
On 2015-08-25 09:16 (+0200), su_v wrote:
On 2015-05-02 02:04 (+0200), su_v wrote:
On 2015-05-02 01:39 (+0200), Alex Valavanis wrote:
My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Mac OS X 10.7.5, Xcode 4.3.2:
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
checking whether llvm-g++-4.2 supports C++11 features by default... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++0x... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
- Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++0x... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
After upgrading to Xcode 4.6.3 (latest Xcode release for OS X 10.7.5):
- $ clang --version Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Default configure output ($CXX is /usr/bin/clang++):
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... yes
If configure is run with "-std=c++11 -stdlib=libstdc++" added to CXXFLAGS:
checking whether /usr/bin/clang++ supports C++11 features by default... yes
It appears that this specific AX macro detects C++11 support with the newer clang version shipped with Xcode 4.6.3, but I don't know how that would work out if Inkscape actually used them freely (C++ runtime is still libstdc++ from GCC 4.2.1, in either case). Any chance for more fine-grained tests, based on specific C++11 features?
IIUC Cmake 3.3.x runs internal compiler tests for supported c++98 and C++11 features - the C++11-related snippet from ${cmake_build_dir}/CMakeFiles/CMakeOutput.log is attached.
Again - I'm uncertain what to make of this...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
XCode 4.6 requires 10.7 Lion.
-Pete (via mobile)
On Aug 25, 2015, at 7:59 AM, Alex Valavanis <valavanisalex@...400...> wrote:
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
AV
On 25 August 2015 at 08:46, su_v <suv@...2204...> wrote:
On 2015-08-25 09:16 (+0200), su_v wrote:
On 2015-05-02 02:04 (+0200), su_v wrote:
On 2015-05-02 01:39 (+0200), Alex Valavanis wrote: My test branch has an autotools test for basic C++11 compatibility (no new . Before I start adding any new features, please could some of the OS X or legacy support testers have a go at running the configure script on that branch and let me know how it goes? I suspect we'll need much more fine-grained feature tests if we're hoping to support older compilers
Branch is at
lp:~valavanisalex/inkscape/cpp11-port http://code.launchpad.net/~valavanisalex/inkscape/cpp11-port
Mac OS X 10.7.5, Xcode 4.3.2:
- i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
checking whether llvm-g++-4.2 supports C++11 features by default... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=gnu++0x... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++11... no checking whether llvm-g++-4.2 supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
- Apple clang version 3.1 (tags/Apple/clang-318.0.58) (based on LLVM 3.1svn)
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++0x... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++11... no checking whether /usr/bin/clang++ supports C++11 features with -std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.
After upgrading to Xcode 4.6.3 (latest Xcode release for OS X 10.7.5):
- $ clang --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Default configure output ($CXX is /usr/bin/clang++):
checking whether /usr/bin/clang++ supports C++11 features by default... no checking whether /usr/bin/clang++ supports C++11 features with -std=gnu++11... yes
If configure is run with "-std=c++11 -stdlib=libstdc++" added to CXXFLAGS:
checking whether /usr/bin/clang++ supports C++11 features by default... yes
It appears that this specific AX macro detects C++11 support with the newer clang version shipped with Xcode 4.6.3, but I don't know how that would work out if Inkscape actually used them freely (C++ runtime is still libstdc++ from GCC 4.2.1, in either case). Any chance for more fine-grained tests, based on specific C++11 features?
IIUC Cmake 3.3.x runs internal compiler tests for supported c++98 and C++11 features - the C++11-related snippet from ${cmake_build_dir}/CMakeFiles/CMakeOutput.log is attached.
Again - I'm uncertain what to make of this...
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-08-25 16:59 (+0200), Alex Valavanis wrote:
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
Xcode 4.6: OS X 10.7 Lion Xcode 5.x: OS X 10.8 Mountain Lion Xcode 6.2: OS X 10.9 Mavericks Xcode 6.4: OS X 10.10 Yosemite
Is Xcode the only way to compile anything on OS X? (I'm completely unfamiliar with that platform.)
On the Linux side, I think we can safely assume C++11 support no worse than in GCC 4.8.4 (the version from current Ubuntu LTS).
Regards, Krzysztof
2015-08-25 18:25 GMT+02:00 su_v <suv@...2204...>:
On 2015-08-25 16:59 (+0200), Alex Valavanis wrote:
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
Xcode 4.6: OS X 10.7 Lion Xcode 5.x: OS X 10.8 Mountain Lion Xcode 6.2: OS X 10.9 Mavericks Xcode 6.4: OS X 10.10 Yosemite
See also: https://trac.macports.org/wiki/XcodeVersionInfo
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 2015-08-26 02:46 (+0200), Krzysztof Kosiński wrote:
Is Xcode the only way to compile anything on OS X? (I'm completely unfamiliar with that platform.)
Xcode and Xcode's CLT [1] are a prerequisite (default toolchain) for any of the major package managers on OS X (MacPorts, Fink, Homebrew, gtk-osx) which ease getting all the dependencies for GTK+ and Inkscape installed. Besides Apple's compiler toolchain (compatible with the system runtimes) Xcode provides the SDKs for building against Apple's frameworks.
* As likely mentioned a few times in earlier threads, it is technically possible to build a custom (newer) compiler toolchain (be it for FSF GCC or Clang) from source; it is technically also possible to compile the dependencies as well as Inkscape itself from source using that custom compiler. As long as nothing pulls in system libs or frameworks which are linked against an incompatible system C++ runtime, this might produce stable inkscape binaries. Both can be attempted via MacPorts, too, though the part of rebuilding the tree itself with that custom compiler to avoid any mixing of different (incompatible) C++ runtimes is not an officially supported MacPorts configuration. * On OS X 10.7 (Lion) and OS X 10.8 (Mountain Lion), it is technically possible to recompile the dependency tree with Apple's system compiler (clang), and switch the C++ runtime from GCC's 4.2.1 libstdc++ to libc++ via CXXFLAGS or command line arguments passed to the compiler [2]. The success rate of this strategy is not known to me - Lion's libc++ is likely rather dated, and breakages of some of the dependencies to be expected (various build systems may make assumptions about what to use on OS X, and override/ignore custom configurations). Again not an officially supported configuration within MacPorts [3]. * Alternative package managers (e.g. Fink, Homebrew) may have developed their own solutions to support modern C++11-based ports/packages on older versions of OS X (I haven't investigated in detail since MacPorts is my preferred tool for installing Inkscape's dependencies, and served me well for this purpose in the past) - the overall tendency though seems to be that full support for older versions of OS X is waning (i.e. depending on what individual developers and port/package maintainers are willing/able to sustain - some might choose to follow what appears to be Apple's policy: current and past two versions only).
It was my personal choice (for several reasons) not to attempt a strategy based on custom compiler toolchain(s) again - neither for local Unix-style trunk/release branch builds, nor for osx packaging (creating relocatable and fully self-contained application bundles).
Since having the role of a single person currently stuck with an outdated version of a proprietary OS who is holding back all of Inkscape's development makes me increasingly uncomfortable (some of the reasons I'm "stuck" like this are of personal nature and not strictly technical (or monetary)), I suggest that the project moves on, officially ends support for OS X < 10.9 (if someone volunteers to attempt to create pre-compiled packages for <= 10.8 that would be a bonus), and opens trunk for C++11 features without restrictions ASAP.
Once my personal circumstances change and I have access to a modern compiler toolchain with full C++11 support (preferably provided by the system), I'll likely pick up bug triage again, possibly packaging (or at least the osxmenu branch), too.
Regards, V
[1] CLT: Command Line Tools Package - available for download separately from Xcode which allows to do UNIX-style command line development in OS X. [2] https://trac.macports.org/wiki/LibcxxOnOlderSystems [3] recent example: "ncurses @6.0_0 fails to build on Lion with cxx_stdlib=libc++" https://trac.macports.org/ticket/48627#comment:9
On the Linux side, I think we can safely assume C++11 support no worse than in GCC 4.8.4 (the version from current Ubuntu LTS).
Regards, Krzysztof
2015-08-25 18:25 GMT+02:00 su_v <suv@...2204...>:
On 2015-08-25 16:59 (+0200), Alex Valavanis wrote:
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
Xcode 4.6: OS X 10.7 Lion Xcode 5.x: OS X 10.8 Mountain Lion Xcode 6.2: OS X 10.9 Mavericks Xcode 6.4: OS X 10.10 Yosemite
@suv - I'm sure everyone will agree with me, though, that you're one of the most valued members of the project... I really think that locking you out of compiling the latest development version should be our very last resort!
Best wishes,
Alex On 26 Aug 2015 2:16 pm, "su_v" <suv@...2204...> wrote:
On 2015-08-26 02:46 (+0200), Krzysztof Kosiński wrote:
Is Xcode the only way to compile anything on OS X? (I'm completely unfamiliar with that platform.)
Xcode and Xcode's CLT [1] are a prerequisite (default toolchain) for any of the major package managers on OS X (MacPorts, Fink, Homebrew, gtk-osx) which ease getting all the dependencies for GTK+ and Inkscape installed. Besides Apple's compiler toolchain (compatible with the system runtimes) Xcode provides the SDKs for building against Apple's frameworks.
- As likely mentioned a few times in earlier threads, it is technically
possible to build a custom (newer) compiler toolchain (be it for FSF GCC or Clang) from source; it is technically also possible to compile the dependencies as well as Inkscape itself from source using that custom compiler. As long as nothing pulls in system libs or frameworks which are linked against an incompatible system C++ runtime, this might produce stable inkscape binaries. Both can be attempted via MacPorts, too, though the part of rebuilding the tree itself with that custom compiler to avoid any mixing of different (incompatible) C++ runtimes is not an officially supported MacPorts configuration.
- On OS X 10.7 (Lion) and OS X 10.8 (Mountain Lion), it is technically
possible to recompile the dependency tree with Apple's system compiler (clang), and switch the C++ runtime from GCC's 4.2.1 libstdc++ to libc++ via CXXFLAGS or command line arguments passed to the compiler [2]. The success rate of this strategy is not known to me - Lion's libc++ is likely rather dated, and breakages of some of the dependencies to be expected (various build systems may make assumptions about what to use on OS X, and override/ignore custom configurations). Again not an officially supported configuration within MacPorts [3].
- Alternative package managers (e.g. Fink, Homebrew) may have developed
their own solutions to support modern C++11-based ports/packages on older versions of OS X (I haven't investigated in detail since MacPorts is my preferred tool for installing Inkscape's dependencies, and served me well for this purpose in the past) - the overall tendency though seems to be that full support for older versions of OS X is waning (i.e. depending on what individual developers and port/package maintainers are willing/able to sustain - some might choose to follow what appears to be Apple's policy: current and past two versions only).
It was my personal choice (for several reasons) not to attempt a strategy based on custom compiler toolchain(s) again - neither for local Unix-style trunk/release branch builds, nor for osx packaging (creating relocatable and fully self-contained application bundles).
Since having the role of a single person currently stuck with an outdated version of a proprietary OS who is holding back all of Inkscape's development makes me increasingly uncomfortable (some of the reasons I'm "stuck" like this are of personal nature and not strictly technical (or monetary)), I suggest that the project moves on, officially ends support for OS X < 10.9 (if someone volunteers to attempt to create pre-compiled packages for <= 10.8 that would be a bonus), and opens trunk for C++11 features without restrictions ASAP.
Once my personal circumstances change and I have access to a modern compiler toolchain with full C++11 support (preferably provided by the system), I'll likely pick up bug triage again, possibly packaging (or at least the osxmenu branch), too.
Regards, V
[1] CLT: Command Line Tools Package - available for download separately from Xcode which allows to do UNIX-style command line development in OS X. [2] https://trac.macports.org/wiki/LibcxxOnOlderSystems [3] recent example: "ncurses @6.0_0 fails to build on Lion with cxx_stdlib=libc++" https://trac.macports.org/ticket/48627#comment:9
On the Linux side, I think we can safely assume C++11 support no worse than in GCC 4.8.4 (the version from current Ubuntu LTS).
Regards, Krzysztof
2015-08-25 18:25 GMT+02:00 su_v <suv@...2204...>:
On 2015-08-25 16:59 (+0200), Alex Valavanis wrote:
The AX macro tests for a few C++11 features (not just support for the command-line flag) but it isn't comprehensive. Still, this looks like good progress. AFAIK, Xcode 5.0 would be needed for full C++11 support.
Do you know which is the earliest OS X version that will run Xcode 4.6?
Xcode 4.6: OS X 10.7 Lion Xcode 5.x: OS X 10.8 Mountain Lion Xcode 6.2: OS X 10.9 Mavericks Xcode 6.4: OS X 10.10 Yosemite
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
participants (10)
-
Alex Valavanis -
Bryce Harrington -
Gez -
Jabier Arraiza (Marker) -
Johan Engelen -
Jon A. Cruz -
Krzysztof Kosiński -
Martin Owens -
Peter Tripp -
su_v