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?

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::vector<Inkscape::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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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.

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(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

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 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

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.

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: > > 1) 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. > > 2) 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?

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: >>> >>> 1) 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. >>> >>> 2) 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? > > 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(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/inkscape-devel ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)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 See also: https://trac.macports.org/wiki/XcodeVersionInfo ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)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 >> >> See also: >> https://trac.macports.org/wiki/XcodeVersionInfo ------------------------------------------------------------------------------ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel