From sacadmin Fri Feb 1 00:38:33 2008 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m118cXvN024581; Fri, 1 Feb 2008 00:38:33 -0800 (PST) Received: (from sh162551@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m118cXBF024576; Fri, 1 Feb 2008 00:38:33 -0800 (PST) Date: Fri, 1 Feb 2008 00:38:33 -0800 (PST) From: Shi-Ying Irene Huang Message-Id: <200802010838.m118cXBF024576@sac.sfbay.sun.com> To: LSARC@sac.sfbay.sun.com Cc: jds-dev@sun.com Subject: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] Status: RO Content-Length: 10614 Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana 1.2. Name of Document Author/Supplier: Author: Chris Wang 1.3 Date of This Document: 01 February, 2008 4. Technical Description This information is Copyright 2006 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng 1.3. Date of This Document: 01/30/08 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer:ghee.teo@sun.com, chris.wang@sun.com, elaine.xiong@sun.com, simon.zheng@sun.com 2. Project Summary 2.1. Project Description: libsigc++ implements a typesafe callback system for use in widget libraries, abstract interfaces, and general programming. It allows users to define signals and to connect those signals to any callback function, either global or a member function, regardless of whether it is static or virtual. It contains adaptor classes for connecting dissimilar callbacks and has an ease of use unmatched by other C++ callback libraries. cairomm is a C++ wrapper for the cairo graphics library. It offers all the power of cairo with an interface familiar to C++ developers, including use of the Standard Template Library where it makes sense. Even though cairomm can be used on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. glibmm is a set of C++ bindings for Glib2 Library, including cross-platform APIs such as a std::string-like UTF8 string class, string utility methods, such as a text encoding converter API, file access, and threads. gtkmm is the official C++ interface for the popular GUI library GTK+. Highlights include typesafe callbacks, and a comprehensive set of widgets that are easily extensible via inheritance. You can create user interfaces either in code or with the Glade User Interface designer, using libglademm. There's extensive documentation, including API reference and a tutorial. 2.2. Risks and Assumptions: gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees API/ABI-stability and new releases on a predictable schedule, delivering C++ API for the underlying GTK+ and GNOME APIs as soon as possible. The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build any 64-bit binaries that are actually usable, we only deliver these packages build with Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's responsibility to fix the build problems. 4. Technical Description: 4.1. Details: libsigc++ provides the following Features: - Compile time typesafe callbacks (faster than run time checks) - Typesafety violations report line number correctly with template names (no tracing template failures into headers) - No compiler extensions or meta compilers required - Proper handling of dynamic objects and signals (deleted objects will not cause seg faults) - Extendable API at any level: signal, slot, connection and trackable - Extensions do not require alteration of basic components - User definable accumulators - A variety of adaptors to change the callback signature: bind, hide, retype, compose and lambda call groups - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use of the capabilities of Object Oriented Programming language features as in C++. Cairo is a graphics description and rendering library. Cairomm provides classes that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics to be created programmatical in its own language and the be rendered onto surfaces of specific target file formats, such as PostScript,PDF and so on. Current supported rendering surfaces are: - Image Surface (memory buffers) - PDF Surface - PostScript Surface - SVG Surface - Xlib Surface (X11 based systems) - Win32 Surface (Windows) - Quartz Surface (MacOS) - Glitz (OpenGL-accelerated, experimental not fully supported) These surfaces can then be augmented with the upper layer of libraries like that of gtkmm to create GUI application. glibmm develivers a tool called gmmproc that can create gtkmm-style wrapper of glib/GObject-based libraries. For example, gtkmm uses this to generate most of its source code, using .defs files that describe the API of C libraries in a lisp format gtkmm provides the following Features: - Use inheritance to derive custom widgets. - Type-safe signal handlers, in standard C++. - Polymorphism. - Use of Standard C++ Library, including strings, containers, and iterators. - Full internationalisation with UTF8. - Complete C++ memory management - Object composition - Automatic deallocation of dynamically allocated widgets. - Full use of C++ namespaces. - No macros. - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others Free software and free of cost for both Open Source and proprietary development. - Discussed, designed and implemented in public. 4.5. Interfaces: Exported Interfaces Interface Stability Comments --------------------- ---------------- ---------------------- SUNWsigcpp Uncommitted Package names SUNWsigcpp-devel Uncommitted SUNWcairomm Uncommitted SUNWcairomm-devel Uncommitted SUNWglibmm Uncommitted SUNWglibmm-devel Uncommitted SUNWgtkmm Uncommitted SUNWgtkmm-devel Uncommitted /usr/lib/libsigc-2.0.so Volatile /usr/lib/libcairomm-1.0.so Volatile /usr/lib/libglibmm-2.4.so Volatile /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile /usr/lib/glibmm-2.4/proc/gmmproc Volatile /usr/liblibatkmm-1.6.so Volatile /usr/lib/libgtkmm-2.4.so Volatile /usr/lib/libgdkmm-2.4.so Volatile /usr/lib/libpangomm-1.4.so Volatile /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile /usr/lib/sigc++-2.0/include/sigc++config.h Volatile /usr/include/sigc++-2.0 Volatile Directory for hearder files /usr/include/cairomm-1.0 Volatile Directory for header files /usr/include/glibmm-2.4/glibmm Volatile Header files directory /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles /usr/demo/jds/bin/gtkmm-demo Volatile /usr/lib/pkgconfig/atkmm-1.6.pc Volatile /usr/lib/pkgconfig/gtkmm-2.4.pc Volatile /usr/lib/pkgconfig/pangomm-1.4.pc Volatile /usr/lib/pkgconfig/cairomm-1.0.pc Volatile /usr/lib/pkgconfig/sigc++-2.0.pc Volatile /usr/lib/pkgconfig/glibmm-2.4.pc Volatile Imported Interfaces Interface Stability Comments --------------------- ---------------- ---------------------- GNOME Committed Platform Libraries Committed LSARC/2007/520 GNOME 2.20 GTK+ library 4.9. I18N/L10N Impact: The JDS team and the G11N are working together to evaluation and provide I18N/L10N support 4.10. Packaging & Delivery: The project will be delivering the following packages: SUNWgtkmm SUNWgtkmm-devel SUNWglibmm SUNWglibmm-devel SUNWcairomm SUNWcairomm-devel SUNWsigcpp SUNWsigcpp-devel 5. Reference Documents: gtkmm glibmm homepage http://www.gtkmm.org/ cairomm homepage - http://cairographics.org/cairomm cairomm download: http://cairographics.org/releases/ libsigc++ Homepage - http://libsigc.sourceforge.net libsigc++ Tutorial - http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From sacadmin Fri Feb 1 07:55:23 2008 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m11FtN6B003576; Fri, 1 Feb 2008 07:55:23 -0800 (PST) Received: from [192.168.0.101] (vpn-129-150-19-95.SFBay.Sun.COM [129.150.19.95]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m11FtKx8017280; Fri, 1 Feb 2008 07:55:22 -0800 (PST) Message-ID: <47A340E4.2080600@sun.com> Date: Fri, 01 Feb 2008 07:55:16 -0800 From: Alan Coopersmith User-Agent: Thunderbird 1.5.0.4 (X11/20060602) MIME-Version: 1.0 To: Shi-Ying Irene Huang CC: LSARC@sac.sfbay.sun.com, jds-dev@sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> In-Reply-To: <200802010838.m118cXBF024576@sac.sfbay.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 418 Shi-Ying Irene Huang wrote: > This information is > Sun XXXprietary/XXXfidential: Internal Use Only: Engineering Need-to-Know > 6.6. ARC Exposure: open You cannot have both those statements in the case - either it's open to the community or it's a secret for Sun eyes only, but it can't be both. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Fri Feb 1 18:42:47 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m122glBq006834 for ; Fri, 1 Feb 2008 18:42:47 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m122gkMQ041706 for ; Fri, 1 Feb 2008 18:42:47 -0800 (PST) Received: from fe-apac-01.sun.com (fe-apac-01.sun.com [192.18.19.172] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m122gh5B019119 for ; Sat, 2 Feb 2008 02:42:43 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVL0010195YWC00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM) for LSARC@sac.sfbay.sun.com; Sat, 02 Feb 2008 10:42:41 +0800 (SGT) Received: from [129.150.144.32] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVL008NGBJ4FEC0@mail-apac.sun.com>; Sat, 02 Feb 2008 10:42:41 +0800 (SGT) Date: Sat, 02 Feb 2008 10:42:43 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A340E4.2080600@sun.com> Sender: Irene.Huang@sun.com To: Alan Coopersmith , LSARC , JDS Dev Message-id: <47A3D8A3.5070003@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A340E4.2080600@sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 490 Removed from the case log, I'll send out an email to include lsarc-ext@sun.com for review without the comment. Thanks for the reminder. --Irene Alan Coopersmith wrote: > Shi-Ying Irene Huang wrote: >> This information is Sun XXXprietary/XXXfidential: Internal Use Only: >> Engineering Need-to-Know > >> 6.6. ARC Exposure: open > > You cannot have both those statements in the case - either it's > open to the community or it's a secret for Sun eyes only, but it > can't be both. > From Irene.Huang@sun.com Fri Feb 1 18:46:52 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m122kpEj007101 for ; Fri, 1 Feb 2008 18:46:51 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m122kmLa017922; Sat, 2 Feb 2008 02:46:50 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVL00903BQ1VL00@brm-avmta-1.central.sun.com>; Fri, 01 Feb 2008 19:46:49 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVL004EKBQ0M5D0@brm-avmta-1.central.sun.com>; Fri, 01 Feb 2008 19:46:49 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m122knwT019160; Sat, 02 Feb 2008 02:46:49 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVL00201BGSW200@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Sat, 02 Feb 2008 10:46:47 +0800 (SGT) Received: from [129.150.144.32] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVL003KABPYMWJT@mail-apac.sun.com>; Sat, 02 Feb 2008 10:46:47 +0800 (SGT) Date: Sat, 02 Feb 2008 10:46:50 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <200802010838.m118cXBF024576@sac.sfbay.sun.com> Sender: Irene.Huang@sun.com To: Shi-Ying Irene Huang Cc: LSARC@sac.sfbay.sun.com, jds-dev@sun.com, lsarc-ext@sun.com Message-id: <47A3D99A.7080201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 10707 Including lsarc-ext since this case is open. Thanks --Irene Shi-Ying Irene Huang wrote: > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm > > 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng > > 1.3. Date of This Document: 01/30/08 > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@sun.com > 1.5.2. Responsible Engineer:ghee.teo@sun.com, > chris.wang@sun.com, > elaine.xiong@sun.com, > simon.zheng@sun.com > > 2. Project Summary > 2.1. Project Description: > libsigc++ implements a typesafe callback system for use in widget libraries, > abstract interfaces, and general programming. It allows users to define > signals and to connect those signals to any callback function, either global > or a member function, regardless of whether it is static or virtual. > It contains adaptor classes for connecting dissimilar callbacks and has an ease > of use unmatched by other C++ callback libraries. > > cairomm is a C++ wrapper for the cairo graphics library. It offers all the power > of cairo with an interface familiar to C++ developers, including use of the > Standard Template Library where it makes sense. Even though cairomm can be used > on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. > > glibmm is a set of C++ bindings for Glib2 Library, including cross-platform > APIs such as a std::string-like UTF8 string class, string utility > methods, such as a text encoding converter API, file access, and > threads. > > gtkmm is the official C++ interface for the popular GUI library GTK+. > Highlights include typesafe callbacks, and a comprehensive set of widgets > that are easily extensible via inheritance. You can create user interfaces either in > code or with the Glade User Interface designer, using libglademm. There's > extensive documentation, including API reference and a tutorial. > > > > 2.2. Risks and Assumptions: > gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees > API/ABI-stability and new releases on a predictable schedule, delivering C++ API for > the underlying GTK+ and GNOME APIs as soon as possible. > > The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and > GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, > but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained > a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build > any 64-bit binaries that are actually usable, we only deliver these packages build with > Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's > responsibility to fix the build problems. > > 4. Technical Description: > 4.1. Details: > libsigc++ provides the following Features: > > - Compile time typesafe callbacks (faster than run time checks) > - Typesafety violations report line number correctly with template names > (no tracing template failures into headers) > - No compiler extensions or meta compilers required > - Proper handling of dynamic objects and signals (deleted objects will not cause seg faults) > - Extendable API at any level: signal, slot, connection and trackable > - Extensions do not require alteration of basic components > - User definable accumulators > - A variety of adaptors to change the callback signature: bind, hide, retype, > compose and lambda call groups > - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, > Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. > > cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use > of the capabilities of Object Oriented Programming language features as in C++. > > Cairo is a graphics description and rendering library. Cairomm provides classes > that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics > to be created programmatical in its own language and the be rendered onto surfaces of specific > target file formats, such as PostScript,PDF and so on. > Current supported rendering surfaces are: > - Image Surface (memory buffers) > - PDF Surface > - PostScript Surface > - SVG Surface > - Xlib Surface (X11 based systems) > - Win32 Surface (Windows) > - Quartz Surface (MacOS) > - Glitz (OpenGL-accelerated, experimental not fully supported) > > These surfaces can then be augmented with the upper layer of libraries like that of gtkmm > to create GUI application. > > glibmm develivers a tool called gmmproc that can create gtkmm-style wrapper of > glib/GObject-based libraries. For example, gtkmm uses this to generate most of > its source code, using .defs files that describe the API of C libraries in a lisp format > > gtkmm provides the following Features: > - Use inheritance to derive custom widgets. > - Type-safe signal handlers, in standard C++. > - Polymorphism. > - Use of Standard C++ Library, including strings, containers, and iterators. > - Full internationalisation with UTF8. > - Complete C++ memory management > - Object composition > - Automatic deallocation of dynamically allocated widgets. > - Full use of C++ namespaces. > - No macros. > - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), > Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others > Free software and free of cost for both Open Source and proprietary development. > - Discussed, designed and implemented in public. > > > 4.5. Interfaces: > > Exported Interfaces > Interface Stability Comments > --------------------- ---------------- ---------------------- > SUNWsigcpp Uncommitted Package names > SUNWsigcpp-devel Uncommitted > SUNWcairomm Uncommitted > SUNWcairomm-devel Uncommitted > SUNWglibmm Uncommitted > SUNWglibmm-devel Uncommitted > SUNWgtkmm Uncommitted > SUNWgtkmm-devel Uncommitted > > /usr/lib/libsigc-2.0.so Volatile > /usr/lib/libcairomm-1.0.so Volatile > /usr/lib/libglibmm-2.4.so Volatile > /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile > /usr/lib/glibmm-2.4/proc/gmmproc Volatile > /usr/liblibatkmm-1.6.so Volatile > /usr/lib/libgtkmm-2.4.so Volatile > /usr/lib/libgdkmm-2.4.so Volatile > /usr/lib/libpangomm-1.4.so Volatile > /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile > /usr/lib/sigc++-2.0/include/sigc++config.h Volatile > > /usr/include/sigc++-2.0 Volatile Directory for hearder files > /usr/include/cairomm-1.0 Volatile Directory for header files > /usr/include/glibmm-2.4/glibmm Volatile Header files directory > /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory > /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles > /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles > /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles > /usr/demo/jds/bin/gtkmm-demo Volatile > > /usr/lib/pkgconfig/atkmm-1.6.pc Volatile > /usr/lib/pkgconfig/gtkmm-2.4.pc Volatile > /usr/lib/pkgconfig/pangomm-1.4.pc Volatile > /usr/lib/pkgconfig/cairomm-1.0.pc Volatile > /usr/lib/pkgconfig/sigc++-2.0.pc Volatile > /usr/lib/pkgconfig/glibmm-2.4.pc Volatile > > Imported Interfaces > Interface Stability Comments > --------------------- ---------------- ---------------------- > > GNOME Committed Platform Libraries Committed LSARC/2007/520 > GNOME 2.20 > GTK+ library > > 4.9. I18N/L10N Impact: > The JDS team and the G11N are working together to evaluation and > provide I18N/L10N support > > 4.10. Packaging & Delivery: > The project will be delivering the following packages: > SUNWgtkmm > SUNWgtkmm-devel > SUNWglibmm > SUNWglibmm-devel > SUNWcairomm > SUNWcairomm-devel > SUNWsigcpp > SUNWsigcpp-devel > > > 5. Reference Documents: > gtkmm glibmm homepage http://www.gtkmm.org/ > cairomm homepage - http://cairographics.org/cairomm > cairomm download: http://cairographics.org/releases/ > libsigc++ Homepage - http://libsigc.sourceforge.net > libsigc++ Tutorial - http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ > libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > JDS > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From sacadmin Fri Feb 1 18:47:07 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m122l7iF007105; Fri, 1 Feb 2008 18:47:07 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m122kr21040001; Fri, 1 Feb 2008 18:46:53 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m122kpSW002975; Sat, 2 Feb 2008 02:46:51 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVL00201BGSW200@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Sat, 02 Feb 2008 10:46:47 +0800 (SGT) Received: from [129.150.144.32] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVL003KABPYMWJT@mail-apac.sun.com>; Sat, 02 Feb 2008 10:46:47 +0800 (SGT) Date: Sat, 02 Feb 2008 10:46:50 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <200802010838.m118cXBF024576@sac.sfbay.sun.com> Sender: Irene.Huang@sun.com To: Shi-Ying Irene Huang Cc: LSARC@sac.sfbay.sun.com, jds-dev@sun.com, lsarc-ext@sun.com Message-id: <47A3D99A.7080201@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 10707 Including lsarc-ext since this case is open. Thanks --Irene Shi-Ying Irene Huang wrote: > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > This information is Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm > > 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng > > 1.3. Date of This Document: 01/30/08 > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@sun.com > 1.5.2. Responsible Engineer:ghee.teo@sun.com, > chris.wang@sun.com, > elaine.xiong@sun.com, > simon.zheng@sun.com > > 2. Project Summary > 2.1. Project Description: > libsigc++ implements a typesafe callback system for use in widget libraries, > abstract interfaces, and general programming. It allows users to define > signals and to connect those signals to any callback function, either global > or a member function, regardless of whether it is static or virtual. > It contains adaptor classes for connecting dissimilar callbacks and has an ease > of use unmatched by other C++ callback libraries. > > cairomm is a C++ wrapper for the cairo graphics library. It offers all the power > of cairo with an interface familiar to C++ developers, including use of the > Standard Template Library where it makes sense. Even though cairomm can be used > on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. > > glibmm is a set of C++ bindings for Glib2 Library, including cross-platform > APIs such as a std::string-like UTF8 string class, string utility > methods, such as a text encoding converter API, file access, and > threads. > > gtkmm is the official C++ interface for the popular GUI library GTK+. > Highlights include typesafe callbacks, and a comprehensive set of widgets > that are easily extensible via inheritance. You can create user interfaces either in > code or with the Glade User Interface designer, using libglademm. There's > extensive documentation, including API reference and a tutorial. > > > > 2.2. Risks and Assumptions: > gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees > API/ABI-stability and new releases on a predictable schedule, delivering C++ API for > the underlying GTK+ and GNOME APIs as soon as possible. > > The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and > GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, > but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained > a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build > any 64-bit binaries that are actually usable, we only deliver these packages build with > Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's > responsibility to fix the build problems. > > 4. Technical Description: > 4.1. Details: > libsigc++ provides the following Features: > > - Compile time typesafe callbacks (faster than run time checks) > - Typesafety violations report line number correctly with template names > (no tracing template failures into headers) > - No compiler extensions or meta compilers required > - Proper handling of dynamic objects and signals (deleted objects will not cause seg faults) > - Extendable API at any level: signal, slot, connection and trackable > - Extensions do not require alteration of basic components > - User definable accumulators > - A variety of adaptors to change the callback signature: bind, hide, retype, > compose and lambda call groups > - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, > Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. > > cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use > of the capabilities of Object Oriented Programming language features as in C++. > > Cairo is a graphics description and rendering library. Cairomm provides classes > that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics > to be created programmatical in its own language and the be rendered onto surfaces of specific > target file formats, such as PostScript,PDF and so on. > Current supported rendering surfaces are: > - Image Surface (memory buffers) > - PDF Surface > - PostScript Surface > - SVG Surface > - Xlib Surface (X11 based systems) > - Win32 Surface (Windows) > - Quartz Surface (MacOS) > - Glitz (OpenGL-accelerated, experimental not fully supported) > > These surfaces can then be augmented with the upper layer of libraries like that of gtkmm > to create GUI application. > > glibmm develivers a tool called gmmproc that can create gtkmm-style wrapper of > glib/GObject-based libraries. For example, gtkmm uses this to generate most of > its source code, using .defs files that describe the API of C libraries in a lisp format > > gtkmm provides the following Features: > - Use inheritance to derive custom widgets. > - Type-safe signal handlers, in standard C++. > - Polymorphism. > - Use of Standard C++ Library, including strings, containers, and iterators. > - Full internationalisation with UTF8. > - Complete C++ memory management > - Object composition > - Automatic deallocation of dynamically allocated widgets. > - Full use of C++ namespaces. > - No macros. > - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), > Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others > Free software and free of cost for both Open Source and proprietary development. > - Discussed, designed and implemented in public. > > > 4.5. Interfaces: > > Exported Interfaces > Interface Stability Comments > --------------------- ---------------- ---------------------- > SUNWsigcpp Uncommitted Package names > SUNWsigcpp-devel Uncommitted > SUNWcairomm Uncommitted > SUNWcairomm-devel Uncommitted > SUNWglibmm Uncommitted > SUNWglibmm-devel Uncommitted > SUNWgtkmm Uncommitted > SUNWgtkmm-devel Uncommitted > > /usr/lib/libsigc-2.0.so Volatile > /usr/lib/libcairomm-1.0.so Volatile > /usr/lib/libglibmm-2.4.so Volatile > /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile > /usr/lib/glibmm-2.4/proc/gmmproc Volatile > /usr/liblibatkmm-1.6.so Volatile > /usr/lib/libgtkmm-2.4.so Volatile > /usr/lib/libgdkmm-2.4.so Volatile > /usr/lib/libpangomm-1.4.so Volatile > /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile > /usr/lib/sigc++-2.0/include/sigc++config.h Volatile > > /usr/include/sigc++-2.0 Volatile Directory for hearder files > /usr/include/cairomm-1.0 Volatile Directory for header files > /usr/include/glibmm-2.4/glibmm Volatile Header files directory > /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory > /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles > /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles > /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles > /usr/demo/jds/bin/gtkmm-demo Volatile > > /usr/lib/pkgconfig/atkmm-1.6.pc Volatile > /usr/lib/pkgconfig/gtkmm-2.4.pc Volatile > /usr/lib/pkgconfig/pangomm-1.4.pc Volatile > /usr/lib/pkgconfig/cairomm-1.0.pc Volatile > /usr/lib/pkgconfig/sigc++-2.0.pc Volatile > /usr/lib/pkgconfig/glibmm-2.4.pc Volatile > > Imported Interfaces > Interface Stability Comments > --------------------- ---------------- ---------------------- > > GNOME Committed Platform Libraries Committed LSARC/2007/520 > GNOME 2.20 > GTK+ library > > 4.9. I18N/L10N Impact: > The JDS team and the G11N are working together to evaluation and > provide I18N/L10N support > > 4.10. Packaging & Delivery: > The project will be delivering the following packages: > SUNWgtkmm > SUNWgtkmm-devel > SUNWglibmm > SUNWglibmm-devel > SUNWcairomm > SUNWcairomm-devel > SUNWsigcpp > SUNWsigcpp-devel > > > 5. Reference Documents: > gtkmm glibmm homepage http://www.gtkmm.org/ > cairomm homepage - http://cairographics.org/cairomm > cairomm download: http://cairographics.org/releases/ > libsigc++ Homepage - http://libsigc.sourceforge.net > libsigc++ Tutorial - http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ > libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ > > > 6. Resources and Schedule > 6.4. Steering Committee requested information > 6.4.1. Consolidation C-team Name: > JDS > 6.5. ARC review type: FastTrack > 6.6. ARC Exposure: open > > From Laszlo.Peter@sun.com Mon Feb 4 20:28:12 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m154SBfQ011635 for ; Mon, 4 Feb 2008 20:28:11 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m154S1pf008725; Tue, 5 Feb 2008 04:28:10 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00L070EV4G00@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 21:28:07 -0700 (MST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR007L80EUXF90@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 21:28:07 -0700 (MST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m154S52f015863; Tue, 05 Feb 2008 04:28:05 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00L010CNDI00@fe-emea-09.sun.com> (original mail from Laszlo.Peter@Sun.COM); Tue, 05 Feb 2008 04:28:05 +0000 (GMT) Received: from [192.168.2.101] ([60.234.117.94]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR00ATI0EPNW30@fe-emea-09.sun.com>; Tue, 05 Feb 2008 04:28:05 +0000 (GMT) Date: Tue, 05 Feb 2008 17:28:03 +1300 From: "Laszlo (Laca) Peter" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A3D99A.7080201@sun.com> Sender: Laszlo.Peter@sun.com To: lsarc-ext , LSARC@sac.sfbay.sun.com Cc: Shiying Irene Huang , jds-dev Reply-to: laca@sun.com Message-id: <1202185683.1528.70.camel@localhost> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> Status: RO Content-Length: 12283 A question for LSARC regarding these libs: Given that these are c++ libs, is it acceptable to ship duplicate copies built with g++ (/usr/sfw/bin/g++) and if so, where should they be installed? Why would that be useful? For building gtkmm-based applications that are difficult (to say the least) to compile with Sun Studio. An example of such an app is the Inkscape SVG editor. Inkscape builds fine with /usr/sfw/bin/g++, but I was unable to get it built with Sun Studio CC even with the help of the author. The Inkscape codebase is complex and uses lots of template code. When we fixed an error reported by Sun Studio, the new code failed with g++. Obviously, one of the compilers is wrong, but it's also clear that fixing the one that is wrong will require breaking its compatibility. Shipping a g++-built copy of these libs would enable us to build Inkscape without major effort and code changes that cannot be pushed upstream and would potentially allow customers to build other gtkmm-based apps (Gobby? GParted? MySQL Administrator?) that may be difficult to build with Sun Studio. Thanks, Laca On Sat, 2008-02-02 at 10:46 +0800, Irene Huang wrote: > Including lsarc-ext since this case is open. > > Thanks > > --Irene > Shi-Ying Irene Huang wrote: > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > > This information is Copyright 2008 Sun Microsystems > > > > 1. Introduction > > 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm > > > > 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng > > > > 1.3. Date of This Document: 01/30/08 > > > > 1.5. Email Aliases: > > 1.5.1. Responsible Manager: leo.binchy@sun.com > > 1.5.2. Responsible Engineer:ghee.teo@sun.com, > > chris.wang@sun.com, > > elaine.xiong@sun.com, > > simon.zheng@sun.com > > > > 2. Project Summary > > 2.1. Project Description: > > libsigc++ implements a typesafe callback system for use in widget libraries, > > abstract interfaces, and general programming. It allows users to define > > signals and to connect those signals to any callback function, either global > > or a member function, regardless of whether it is static or virtual. > > It contains adaptor classes for connecting dissimilar callbacks and has an ease > > of use unmatched by other C++ callback libraries. > > > > cairomm is a C++ wrapper for the cairo graphics library. It offers all the power > > of cairo with an interface familiar to C++ developers, including use of the > > Standard Template Library where it makes sense. Even though cairomm can be used > > on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. > > > > glibmm is a set of C++ bindings for Glib2 Library, including cross-platform > > APIs such as a std::string-like UTF8 string class, string utility > > methods, such as a text encoding converter API, file access, and > > threads. > > > > gtkmm is the official C++ interface for the popular GUI library GTK+. > > Highlights include typesafe callbacks, and a comprehensive set of widgets > > that are easily extensible via inheritance. You can create user interfaces either in > > code or with the Glade User Interface designer, using libglademm. There's > > extensive documentation, including API reference and a tutorial. > > > > > > > > 2.2. Risks and Assumptions: > > gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees > > API/ABI-stability and new releases on a predictable schedule, delivering C++ API for > > the underlying GTK+ and GNOME APIs as soon as possible. > > > > The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and > > GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, > > but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained > > a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build > > any 64-bit binaries that are actually usable, we only deliver these packages build with > > Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's > > responsibility to fix the build problems. > > > > 4. Technical Description: > > 4.1. Details: > > libsigc++ provides the following Features: > > > > - Compile time typesafe callbacks (faster than run time checks) > > - Typesafety violations report line number correctly with template names > > (no tracing template failures into headers) > > - No compiler extensions or meta compilers required > > - Proper handling of dynamic objects and signals (deleted objects will not cause seg faults) > > - Extendable API at any level: signal, slot, connection and trackable > > - Extensions do not require alteration of basic components > > - User definable accumulators > > - A variety of adaptors to change the callback signature: bind, hide, retype, > > compose and lambda call groups > > - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, > > Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. > > > > cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use > > of the capabilities of Object Oriented Programming language features as in C++. > > > > Cairo is a graphics description and rendering library. Cairomm provides classes > > that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics > > to be created programmatical in its own language and the be rendered onto surfaces of specific > > target file formats, such as PostScript,PDF and so on. > > Current supported rendering surfaces are: > > - Image Surface (memory buffers) > > - PDF Surface > > - PostScript Surface > > - SVG Surface > > - Xlib Surface (X11 based systems) > > - Win32 Surface (Windows) > > - Quartz Surface (MacOS) > > - Glitz (OpenGL-accelerated, experimental not fully supported) > > > > These surfaces can then be augmented with the upper layer of libraries like that of gtkmm > > to create GUI application. > > > > glibmm develivers a tool called gmmproc that can create gtkmm-style wrapper of > > glib/GObject-based libraries. For example, gtkmm uses this to generate most of > > its source code, using .defs files that describe the API of C libraries in a lisp format > > > > gtkmm provides the following Features: > > - Use inheritance to derive custom widgets. > > - Type-safe signal handlers, in standard C++. > > - Polymorphism. > > - Use of Standard C++ Library, including strings, containers, and iterators. > > - Full internationalisation with UTF8. > > - Complete C++ memory management > > - Object composition > > - Automatic deallocation of dynamically allocated widgets. > > - Full use of C++ namespaces. > > - No macros. > > - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), > > Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others > > Free software and free of cost for both Open Source and proprietary development. > > - Discussed, designed and implemented in public. > > > > > > 4.5. Interfaces: > > > > Exported Interfaces > > Interface Stability Comments > > --------------------- ---------------- ---------------------- > > SUNWsigcpp Uncommitted Package names > > SUNWsigcpp-devel Uncommitted > > SUNWcairomm Uncommitted > > SUNWcairomm-devel Uncommitted > > SUNWglibmm Uncommitted > > SUNWglibmm-devel Uncommitted > > SUNWgtkmm Uncommitted > > SUNWgtkmm-devel Uncommitted > > > > /usr/lib/libsigc-2.0.so Volatile > > /usr/lib/libcairomm-1.0.so Volatile > > /usr/lib/libglibmm-2.4.so Volatile > > /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile > > /usr/lib/glibmm-2.4/proc/gmmproc Volatile > > /usr/liblibatkmm-1.6.so Volatile > > /usr/lib/libgtkmm-2.4.so Volatile > > /usr/lib/libgdkmm-2.4.so Volatile > > /usr/lib/libpangomm-1.4.so Volatile > > /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile > > /usr/lib/sigc++-2.0/include/sigc++config.h Volatile > > > > /usr/include/sigc++-2.0 Volatile Directory for hearder files > > /usr/include/cairomm-1.0 Volatile Directory for header files > > /usr/include/glibmm-2.4/glibmm Volatile Header files directory > > /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory > > /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles > > /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles > > /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles > > /usr/demo/jds/bin/gtkmm-demo Volatile > > > > /usr/lib/pkgconfig/atkmm-1.6.pc Volatile > > /usr/lib/pkgconfig/gtkmm-2.4.pc Volatile > > /usr/lib/pkgconfig/pangomm-1.4.pc Volatile > > /usr/lib/pkgconfig/cairomm-1.0.pc Volatile > > /usr/lib/pkgconfig/sigc++-2.0.pc Volatile > > /usr/lib/pkgconfig/glibmm-2.4.pc Volatile > > > > Imported Interfaces > > Interface Stability Comments > > --------------------- ---------------- ---------------------- > > > > GNOME Committed Platform Libraries Committed LSARC/2007/520 > > GNOME 2.20 > > GTK+ library > > > > 4.9. I18N/L10N Impact: > > The JDS team and the G11N are working together to evaluation and > > provide I18N/L10N support > > > > 4.10. Packaging & Delivery: > > The project will be delivering the following packages: > > SUNWgtkmm > > SUNWgtkmm-devel > > SUNWglibmm > > SUNWglibmm-devel > > SUNWcairomm > > SUNWcairomm-devel > > SUNWsigcpp > > SUNWsigcpp-devel > > > > > > 5. Reference Documents: > > gtkmm glibmm homepage http://www.gtkmm.org/ > > cairomm homepage - http://cairographics.org/cairomm > > cairomm download: http://cairographics.org/releases/ > > libsigc++ Homepage - http://libsigc.sourceforge.net > > libsigc++ Tutorial - http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ > > libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ > > > > > > 6. Resources and Schedule > > 6.4. Steering Committee requested information > > 6.4.1. Consolidation C-team Name: > > JDS > > 6.5. ARC review type: FastTrack > > 6.6. ARC Exposure: open > > > > > From sacadmin Mon Feb 4 20:28:12 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m154SCFA011639 for ; Mon, 4 Feb 2008 20:28:12 -0800 (PST) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m154SBl4058769 for ; Mon, 4 Feb 2008 20:28:12 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m154S5Im008288 for ; Tue, 5 Feb 2008 04:28:06 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00L010CNDI00@fe-emea-09.sun.com> (original mail from Laszlo.Peter@Sun.COM) for LSARC@sac.sfbay.sun.com; Tue, 05 Feb 2008 04:28:05 +0000 (GMT) Received: from [192.168.2.101] ([60.234.117.94]) by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR00ATI0EPNW30@fe-emea-09.sun.com>; Tue, 05 Feb 2008 04:28:05 +0000 (GMT) Date: Tue, 05 Feb 2008 17:28:03 +1300 From: "Laszlo (Laca) Peter" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A3D99A.7080201@sun.com> Sender: Laszlo.Peter@sun.com To: lsarc-ext , LSARC@sac.sfbay.sun.com Cc: Shiying Irene Huang , jds-dev Reply-to: laca@sun.com Message-id: <1202185683.1528.70.camel@localhost> Organization: Sun Microsystems, Inc. MIME-version: 1.0 X-Mailer: Evolution 2.12.2 Content-type: text/plain Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> Status: RO Content-Length: 12283 A question for LSARC regarding these libs: Given that these are c++ libs, is it acceptable to ship duplicate copies built with g++ (/usr/sfw/bin/g++) and if so, where should they be installed? Why would that be useful? For building gtkmm-based applications that are difficult (to say the least) to compile with Sun Studio. An example of such an app is the Inkscape SVG editor. Inkscape builds fine with /usr/sfw/bin/g++, but I was unable to get it built with Sun Studio CC even with the help of the author. The Inkscape codebase is complex and uses lots of template code. When we fixed an error reported by Sun Studio, the new code failed with g++. Obviously, one of the compilers is wrong, but it's also clear that fixing the one that is wrong will require breaking its compatibility. Shipping a g++-built copy of these libs would enable us to build Inkscape without major effort and code changes that cannot be pushed upstream and would potentially allow customers to build other gtkmm-based apps (Gobby? GParted? MySQL Administrator?) that may be difficult to build with Sun Studio. Thanks, Laca On Sat, 2008-02-02 at 10:46 +0800, Irene Huang wrote: > Including lsarc-ext since this case is open. > > Thanks > > --Irene > Shi-Ying Irene Huang wrote: > > Template Version: @(#)sac_nextcase 1.64 07/13/07 SMI > > This information is Copyright 2008 Sun Microsystems > > > > 1. Introduction > > 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm > > > > 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng > > > > 1.3. Date of This Document: 01/30/08 > > > > 1.5. Email Aliases: > > 1.5.1. Responsible Manager: leo.binchy@sun.com > > 1.5.2. Responsible Engineer:ghee.teo@sun.com, > > chris.wang@sun.com, > > elaine.xiong@sun.com, > > simon.zheng@sun.com > > > > 2. Project Summary > > 2.1. Project Description: > > libsigc++ implements a typesafe callback system for use in widget libraries, > > abstract interfaces, and general programming. It allows users to define > > signals and to connect those signals to any callback function, either global > > or a member function, regardless of whether it is static or virtual. > > It contains adaptor classes for connecting dissimilar callbacks and has an ease > > of use unmatched by other C++ callback libraries. > > > > cairomm is a C++ wrapper for the cairo graphics library. It offers all the power > > of cairo with an interface familiar to C++ developers, including use of the > > Standard Template Library where it makes sense. Even though cairomm can be used > > on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. > > > > glibmm is a set of C++ bindings for Glib2 Library, including cross-platform > > APIs such as a std::string-like UTF8 string class, string utility > > methods, such as a text encoding converter API, file access, and > > threads. > > > > gtkmm is the official C++ interface for the popular GUI library GTK+. > > Highlights include typesafe callbacks, and a comprehensive set of widgets > > that are easily extensible via inheritance. You can create user interfaces either in > > code or with the Glade User Interface designer, using libglademm. There's > > extensive documentation, including API reference and a tutorial. > > > > > > > > 2.2. Risks and Assumptions: > > gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees > > API/ABI-stability and new releases on a predictable schedule, delivering C++ API for > > the underlying GTK+ and GNOME APIs as soon as possible. > > > > The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and > > GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, > > but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained > > a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build > > any 64-bit binaries that are actually usable, we only deliver these packages build with > > Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's > > responsibility to fix the build problems. > > > > 4. Technical Description: > > 4.1. Details: > > libsigc++ provides the following Features: > > > > - Compile time typesafe callbacks (faster than run time checks) > > - Typesafety violations report line number correctly with template names > > (no tracing template failures into headers) > > - No compiler extensions or meta compilers required > > - Proper handling of dynamic objects and signals (deleted objects will not cause seg faults) > > - Extendable API at any level: signal, slot, connection and trackable > > - Extensions do not require alteration of basic components > > - User definable accumulators > > - A variety of adaptors to change the callback signature: bind, hide, retype, > > compose and lambda call groups > > - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, > > Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. > > > > cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use > > of the capabilities of Object Oriented Programming language features as in C++. > > > > Cairo is a graphics description and rendering library. Cairomm provides classes > > that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics > > to be created programmatical in its own language and the be rendered onto surfaces of specific > > target file formats, such as PostScript,PDF and so on. > > Current supported rendering surfaces are: > > - Image Surface (memory buffers) > > - PDF Surface > > - PostScript Surface > > - SVG Surface > > - Xlib Surface (X11 based systems) > > - Win32 Surface (Windows) > > - Quartz Surface (MacOS) > > - Glitz (OpenGL-accelerated, experimental not fully supported) > > > > These surfaces can then be augmented with the upper layer of libraries like that of gtkmm > > to create GUI application. > > > > glibmm develivers a tool called gmmproc that can create gtkmm-style wrapper of > > glib/GObject-based libraries. For example, gtkmm uses this to generate most of > > its source code, using .defs files that describe the API of C libraries in a lisp format > > > > gtkmm provides the following Features: > > - Use inheritance to derive custom widgets. > > - Type-safe signal handlers, in standard C++. > > - Polymorphism. > > - Use of Standard C++ Library, including strings, containers, and iterators. > > - Full internationalisation with UTF8. > > - Complete C++ memory management > > - Object composition > > - Automatic deallocation of dynamically allocated widgets. > > - Full use of C++ namespaces. > > - No macros. > > - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), > > Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others > > Free software and free of cost for both Open Source and proprietary development. > > - Discussed, designed and implemented in public. > > > > > > 4.5. Interfaces: > > > > Exported Interfaces > > Interface Stability Comments > > --------------------- ---------------- ---------------------- > > SUNWsigcpp Uncommitted Package names > > SUNWsigcpp-devel Uncommitted > > SUNWcairomm Uncommitted > > SUNWcairomm-devel Uncommitted > > SUNWglibmm Uncommitted > > SUNWglibmm-devel Uncommitted > > SUNWgtkmm Uncommitted > > SUNWgtkmm-devel Uncommitted > > > > /usr/lib/libsigc-2.0.so Volatile > > /usr/lib/libcairomm-1.0.so Volatile > > /usr/lib/libglibmm-2.4.so Volatile > > /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile > > /usr/lib/glibmm-2.4/proc/gmmproc Volatile > > /usr/liblibatkmm-1.6.so Volatile > > /usr/lib/libgtkmm-2.4.so Volatile > > /usr/lib/libgdkmm-2.4.so Volatile > > /usr/lib/libpangomm-1.4.so Volatile > > /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile > > /usr/lib/sigc++-2.0/include/sigc++config.h Volatile > > > > /usr/include/sigc++-2.0 Volatile Directory for hearder files > > /usr/include/cairomm-1.0 Volatile Directory for header files > > /usr/include/glibmm-2.4/glibmm Volatile Header files directory > > /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory > > /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles > > /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles > > /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles > > /usr/demo/jds/bin/gtkmm-demo Volatile > > > > /usr/lib/pkgconfig/atkmm-1.6.pc Volatile > > /usr/lib/pkgconfig/gtkmm-2.4.pc Volatile > > /usr/lib/pkgconfig/pangomm-1.4.pc Volatile > > /usr/lib/pkgconfig/cairomm-1.0.pc Volatile > > /usr/lib/pkgconfig/sigc++-2.0.pc Volatile > > /usr/lib/pkgconfig/glibmm-2.4.pc Volatile > > > > Imported Interfaces > > Interface Stability Comments > > --------------------- ---------------- ---------------------- > > > > GNOME Committed Platform Libraries Committed LSARC/2007/520 > > GNOME 2.20 > > GTK+ library > > > > 4.9. I18N/L10N Impact: > > The JDS team and the G11N are working together to evaluation and > > provide I18N/L10N support > > > > 4.10. Packaging & Delivery: > > The project will be delivering the following packages: > > SUNWgtkmm > > SUNWgtkmm-devel > > SUNWglibmm > > SUNWglibmm-devel > > SUNWcairomm > > SUNWcairomm-devel > > SUNWsigcpp > > SUNWsigcpp-devel > > > > > > 5. Reference Documents: > > gtkmm glibmm homepage http://www.gtkmm.org/ > > cairomm homepage - http://cairographics.org/cairomm > > cairomm download: http://cairographics.org/releases/ > > libsigc++ Homepage - http://libsigc.sourceforge.net > > libsigc++ Tutorial - http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ > > libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ > > > > > > 6. Resources and Schedule > > 6.4. Steering Committee requested information > > 6.4.1. Consolidation C-team Name: > > JDS > > 6.5. ARC review type: FastTrack > > 6.6. ARC Exposure: open > > > > > From sacadmin Mon Feb 4 20:42:58 2008 Received: from jurassic-x4600.sfbay.sun.com (cretaceous [129.146.17.63]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m154gwC9011787 for ; Mon, 4 Feb 2008 20:42:58 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m154gvJk586748; Mon, 4 Feb 2008 20:42:58 -0800 (PST) Message-ID: <47A7E83B.9020708@Sun.COM> Date: Mon, 04 Feb 2008 20:38:19 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: laca@sun.com CC: lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev , Rod Evans Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> In-Reply-To: <1202185683.1528.70.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1522 Laszlo (Laca) Peter wrote: > A question for LSARC regarding these libs: > > Given that these are c++ libs, is it acceptable to ship > duplicate copies built with g++ (/usr/sfw/bin/g++) and if > so, where should they be installed? > > Why would that be useful? For building gtkmm-based > applications that are difficult (to say the least) to > compile with Sun Studio. An example of such an app is > the Inkscape SVG editor. Inkscape builds fine with > /usr/sfw/bin/g++, but I was unable to get it built with > Sun Studio CC even with the help of the author. The > Inkscape codebase is complex and uses lots of template > code. When we fixed an error reported by Sun Studio, > the new code failed with g++. Obviously, one of the > compilers is wrong, but it's also clear that fixing > the one that is wrong will require breaking its > compatibility. Shipping a g++-built copy of these > libs would enable us to build Inkscape without major > effort and code changes that cannot be pushed upstream > and would potentially allow customers to build other > gtkmm-based apps (Gobby? GParted? MySQL Administrator?) > that may be difficult to build with Sun Studio. > > Thanks, > Laca > I suggest that we need a minimum of four directories: (32, 64) x (gcc, studio). We should noodle out a design (perhaps w/ help from the linker folks) that will find the appropriate version of the C++ libraries needed. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Mon Feb 4 20:43:05 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m154h4XE011799 for ; Mon, 4 Feb 2008 20:43:05 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m154gxBd009396; Tue, 5 Feb 2008 12:43:01 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR0060713MFU00@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 20:42:58 -0800 (PST) Received: from jurassic-x4600.sfbay.sun.com ([129.146.17.63]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR003NZ13MKS50@nwk-avmta-2.sfbay.sun.com>; Mon, 04 Feb 2008 20:42:58 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by jurassic-x4600.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m154gvJk586748; Mon, 04 Feb 2008 20:42:58 -0800 (PST) Date: Mon, 04 Feb 2008 20:38:19 -0800 From: Bart Smaalders Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <1202185683.1528.70.camel@localhost> To: laca@sun.com Cc: lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev , Rod Evans Message-id: <47A7E83B.9020708@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1522 Laszlo (Laca) Peter wrote: > A question for LSARC regarding these libs: > > Given that these are c++ libs, is it acceptable to ship > duplicate copies built with g++ (/usr/sfw/bin/g++) and if > so, where should they be installed? > > Why would that be useful? For building gtkmm-based > applications that are difficult (to say the least) to > compile with Sun Studio. An example of such an app is > the Inkscape SVG editor. Inkscape builds fine with > /usr/sfw/bin/g++, but I was unable to get it built with > Sun Studio CC even with the help of the author. The > Inkscape codebase is complex and uses lots of template > code. When we fixed an error reported by Sun Studio, > the new code failed with g++. Obviously, one of the > compilers is wrong, but it's also clear that fixing > the one that is wrong will require breaking its > compatibility. Shipping a g++-built copy of these > libs would enable us to build Inkscape without major > effort and code changes that cannot be pushed upstream > and would potentially allow customers to build other > gtkmm-based apps (Gobby? GParted? MySQL Administrator?) > that may be difficult to build with Sun Studio. > > Thanks, > Laca > I suggest that we need a minimum of four directories: (32, 64) x (gcc, studio). We should noodle out a design (perhaps w/ help from the linker folks) that will find the appropriate version of the C++ libraries needed. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From danek.duvall@sun.com Mon Feb 4 21:47:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m155lsPJ012351 for ; Mon, 4 Feb 2008 21:47:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m155lrY7007948; Tue, 5 Feb 2008 13:47:53 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR0040543SWL00@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 22:47:52 -0700 (MST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR007AP43RX8D0@brm-avmta-1.central.sun.com>; Mon, 04 Feb 2008 22:47:51 -0700 (MST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m155lp3N016343; Mon, 04 Feb 2008 21:47:51 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m155loS4009054; Mon, 04 Feb 2008 21:47:51 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m155loEI009053; Mon, 04 Feb 2008 21:47:50 -0800 (PST) Date: Mon, 04 Feb 2008 21:47:50 -0800 From: Danek Duvall Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <200802010838.m118cXBF024576@sac.sfbay.sun.com> To: Shi-Ying Irene Huang Cc: LSARC-ext@sun.com, jds-dev@sun.com Message-id: <20080205054750.GD28799@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 3519 I'll echo Jim's comments in the SQLite case about calling everything Volatile. It's really not appropriate, especially since these are components that exist specifically for other projects to build on top of. Given that these libraries are themselves built on top of the C versions of the same libraries to which we're assigning a "Committed" label, I'd expect that these were at least Uncommitted, if not Committed. Can you provide some rationale for why you expect these interfaces would need to change incompatibly and without warning in patches? Or, better, why they're actually highly unlikely to change incompatibly at all, and thus could be Committed? :) You're also specifying everything by pathname, which is inappropriate. For instance, the .pc files and the directory they live in are Private implementation details, but the base name of the files are the public interfaces that people will use to pass to pkg-config(1). That's how they should be described. > /usr/lib/libsigc-2.0.so Volatile > /usr/lib/libcairomm-1.0.so Volatile > /usr/lib/libglibmm-2.4.so Volatile > /usr/liblibatkmm-1.6.so Volatile > /usr/lib/libgtkmm-2.4.so Volatile > /usr/lib/libgdkmm-2.4.so Volatile > /usr/lib/libpangomm-1.4.so Volatile Are these libraries correctly versioned as described in the libraries best practices document? Do they have their private symbols properly scoped? > /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile Does anyone ever need to link to this library specifically? This seems like a very private implementation detail that should either be a filter library or simply not exist on Solaris. > /usr/lib/glibmm-2.4/proc/gmmproc Volatile What goes here and why is it Public? > /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile > /usr/lib/sigc++-2.0/include/sigc++config.h Volatile Why do we have Public header files under /usr/lib? Such things tend to be Private. > /usr/include/sigc++-2.0 Volatile Directory for hearder files > /usr/include/cairomm-1.0 Volatile Directory for header files > /usr/include/glibmm-2.4/glibmm Volatile Header files directory > /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory These two directories seem rather private, too. > /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles > /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles > /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles > /usr/demo/jds/bin/gtkmm-demo Volatile Here's a general question to the JDS folks -- is it worth making any of these header directories Public at all? It seems that pretty much the only way people know where these things are is through pkg-config(1). Or are these names, complete with version numbers, stable enough that it's what people actually code to? For that matter, are the version numbers of the .pc files stable at all? Danek From Simon.Zheng@sun.com Tue Feb 5 02:20:06 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15AK6Fk019945 for ; Tue, 5 Feb 2008 02:20:06 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m15AK4Dj003231; Tue, 5 Feb 2008 03:20:05 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00F05GPFFD00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 02:20:03 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR00D3AGPAZEA0@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 02:19:59 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m15AK22t009107; Tue, 05 Feb 2008 10:20:02 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVR00801GJY0900@mail-apac.sun.com> (original mail from Simon.Zheng@Sun.COM); Tue, 05 Feb 2008 18:19:58 +0800 (SGT) Received: from [129.158.217.163] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVR007HTGP8BQNZ@mail-apac.sun.com>; Tue, 05 Feb 2008 18:19:57 +0800 (SGT) Date: Tue, 05 Feb 2008 18:19:56 +0800 From: "simon.zheng@sun.com" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080205054750.GD28799@zruty.sfbay.sun.com> Sender: Simon.Zheng@sun.com To: Danek Duvall Cc: Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <47A8384C.4050908@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071105) Status: RO Content-Length: 648 Danek Duvall wrote: > > >> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile >> > > Does anyone ever need to link to this library specifically? This seems > like a very private implementation detail that should either be a filter > library or simply not exist on Solaris. > Fine. I would like let it private. > >> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >> > > What goes here and why is it Public? > Gtkmm or other libraries needs this program to generate gtkmm-style source code, that is, from "*.ccg" to "*.cc" and "*.hg" to "*.h". I want to keep it public. -Simon From danek.duvall@sun.com Tue Feb 5 07:27:08 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15FR8QQ025829 for ; Tue, 5 Feb 2008 07:27:08 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m15FR4MF037446; Tue, 5 Feb 2008 08:27:07 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00K1JUX6WE00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 07:27:06 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR00JY6UX5WK00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 07:27:05 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m15FR4LH035804; Tue, 05 Feb 2008 07:27:04 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m15FR3Mh010209; Tue, 05 Feb 2008 07:27:04 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m15FR31e010208; Tue, 05 Feb 2008 07:27:03 -0800 (PST) Date: Tue, 05 Feb 2008 07:27:01 -0800 From: Danek Duvall Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A8384C.4050908@sun.com> To: "simon.zheng@sun.com" Cc: Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <20080205152701.GE28799@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 676 On Tue, Feb 05, 2008 at 06:19:56PM +0800, simon.zheng@sun.com wrote: > Danek Duvall wrote: > >>> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >> >> What goes here and why is it Public? > > Gtkmm or other libraries needs this program to generate gtkmm-style source > code, that is, from "*.ccg" to "*.cc" and "*.hg" to "*.h". I want to keep > it public. Could you explain the code generation more? What are .ccg and .hg files? I thought one just wrote in C++ to use the *mm versions of the gnome libraries. Is this program invoked from the library code itself, or is it something that people would use directly in a Makefile? THanks, Danek From Brian.Cameron@sun.com Tue Feb 5 07:51:50 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15Fpo8Y025927 for ; Tue, 5 Feb 2008 07:51:50 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m15FphGh014674; Tue, 5 Feb 2008 07:51:49 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00M23W2CX300@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 07:51:48 -0800 (PST) Received: from brmea-mail-2.sun.com ([192.18.98.43]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR00JVHW2AW620@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 07:51:47 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m15FpkmK022472; Tue, 05 Feb 2008 15:51:46 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00M01VZFWR00@mail-amer.sun.com> (original mail from Brian.Cameron@Sun.COM); Tue, 05 Feb 2008 08:51:46 -0700 (MST) Received: from [192.168.1.64] ([189.137.195.67]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR00LZLW1YLV10@mail-amer.sun.com>; Tue, 05 Feb 2008 08:51:39 -0700 (MST) Date: Tue, 05 Feb 2008 09:51:34 -0600 From: Brian Cameron Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A8384C.4050908@sun.com> Sender: Brian.Cameron@sun.com To: "simon.zheng@sun.com" Cc: Danek Duvall , Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <47A88606.8080905@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 573 Simon: >>> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile >>> >> >> Does anyone ever need to link to this library specifically? This seems >> like a very private implementation detail that should either be a filter >> library or simply not exist on Solaris. >> > Fine. I would like let it private. I am confused. You agree to change the interface classification without answering Danek's questions. I think it would be useful to explain how this library is used so we can make sure we set its interface stability level properly. Brian From alan.coopersmith@sun.com Tue Feb 5 08:21:36 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15GLZO9027606 for ; Tue, 5 Feb 2008 08:21:36 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m15GLXtK017095; Wed, 6 Feb 2008 00:21:34 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00B07XFWHK00@brm-avmta-1.central.sun.com>; Tue, 05 Feb 2008 09:21:32 -0700 (MST) Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR0048TXFWCUC0@brm-avmta-1.central.sun.com>; Tue, 05 Feb 2008 09:21:32 -0700 (MST) Received: from [192.168.0.101] (vpn-129-150-19-95.SFBay.Sun.COM [129.150.19.95]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m15GLRri027018; Tue, 05 Feb 2008 08:21:29 -0800 (PST) Date: Tue, 05 Feb 2008 08:21:22 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A88606.8080905@sun.com> To: Brian Cameron Cc: "simon.zheng@sun.com" , Danek Duvall , Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <47A88D02.2030205@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> User-Agent: Thunderbird 1.5.0.4 (X11/20060602) Status: RO Content-Length: 847 Brian Cameron wrote: > > Simon: > >>>> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile >>>> >>> >>> Does anyone ever need to link to this library specifically? This seems >>> like a very private implementation detail that should either be a filter >>> library or simply not exist on Solaris. >>> >> Fine. I would like let it private. > > I am confused. You agree to change the interface classification without > answering Danek's questions. I think it would be useful to explain how > this library is used so we can make sure we set its interface stability > level properly. And if it's Private, why it should be allowed to be in /usr/lib instead of /usr/lib/glibmm-2.4/ or somewhere like that. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Ghee.Teo@sun.com Tue Feb 5 08:42:47 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15Ggl0q028358 for ; Tue, 5 Feb 2008 08:42:47 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m15GglhX001021; Tue, 5 Feb 2008 08:42:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR0030XYFBUG00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 08:42:47 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR00J6PYF8WI70@nwk-avmta-1.sfbay.Sun.COM>; Tue, 05 Feb 2008 08:42:46 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m15Ggi2j023877; Tue, 05 Feb 2008 16:42:44 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00I01Y9PMZ00@fe-emea-10.sun.com> (original mail from Ghee.Teo@Sun.COM) ; Tue, 05 Feb 2008 16:42:44 +0000 (GMT) Received: from [129.156.226.231] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR00007YF8VOE0@fe-emea-10.sun.com>; Tue, 05 Feb 2008 16:42:44 +0000 (GMT) Date: Tue, 05 Feb 2008 16:42:19 +0000 From: Ghee Teo Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080205054750.GD28799@zruty.sfbay.sun.com> Sender: Ghee.Teo@sun.com To: Danek Duvall Cc: Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Reply-to: Ghee.Teo@sun.com Message-id: <47A891EB.8080505@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 5601 Danek Duvall wrote: > I'll echo Jim's comments in the SQLite case about calling everything > Volatile. It's really not appropriate, especially since these are > components that exist specifically for other projects to build on top of. > I take your point about not to throw "Volatile" at everything even the older taxonomy basically said everything External is now named 'Volatile' as according to this document, http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy We could classify these libraries to be Uncommitted (which meant Evolving in the older taxonomy, not the Unstable) for gtkmm, glibmm and cairomm, though we would still keep sigc++ to be Volatile given that it is only a fairly recent addition to the desktop stack. Even though it may sound confusion (Uncommitted sounds as bad as Volatile). > Given that these libraries are themselves built on top of the C versions of > the same libraries to which we're assigning a "Committed" label, I'd expect > that these were at least Uncommitted, if not Committed. > Uncommitted for gtkmm, glibmm and cairomm. > Can you provide some rationale for why you expect these interfaces would > need to change incompatibly and without warning in patches? Or, better, > why they're actually highly unlikely to change incompatibly at all, and > thus could be Committed? :) > > You're also specifying everything by pathname, which is inappropriate. For > instance, the .pc files and the directory they live in are Private > implementation details, but the base name of the files are the public > interfaces that people will use to pass to pkg-config(1). That's how they > should be described. > > >> /usr/lib/libsigc-2.0.so Volatile >> /usr/lib/libcairomm-1.0.so Volatile >> /usr/lib/libglibmm-2.4.so Volatile >> /usr/liblibatkmm-1.6.so Volatile >> /usr/lib/libgtkmm-2.4.so Volatile >> /usr/lib/libgdkmm-2.4.so Volatile >> /usr/lib/libpangomm-1.4.so Volatile >> > > Are these libraries correctly versioned as described in the libraries best > practices document? These libraries versioned are created by the maintainer of the software. For example, even if the version of glib that we built the sample on is 2.14.x, it still produces the version library of libglibmm-2.4. So we can't change these without the risk of being incompatable. > Do they have their private symbols properly scoped? > Based on the current implementation, they are not. > >> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile >> > > Does anyone ever need to link to this library specifically? This seems > like a very private implementation detail that should either be a filter > library or simply not exist on Solaris. > > >> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >> > > What goes here and why is it Public? > > Simon answered this as to why he want this to be public. If it is public, it should be moved to /usr/bin I would think. >> /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile >> /usr/lib/sigc++-2.0/include/sigc++config.h Volatile >> > > Why do we have Public header files under /usr/lib? Such things tend to be > Private. > The above two header files will not be delivered, they are private, required only to build the libraries. > >> /usr/include/sigc++-2.0 Volatile Directory for hearder files >> /usr/include/cairomm-1.0 Volatile Directory for header files >> /usr/include/glibmm-2.4/glibmm Volatile Header files directory >> This one must have. It contains all the header fiels for glibmm >> /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile Header files directory >> > > These two directories seem rather private, too. > This one can possibly removed from interface table. It doesn't seems to do much at the moment. > >> /usr/include/atkmm-1.6 Volatile Directory for atkmm headfiles >> /usr/include/gtkmm-2.4 Volatile Directory for pangomm headfiles >> /usr/include/pangomm-1.4 Volatile Directory for gdkmm headfiles >> /usr/demo/jds/bin/gtkmm-demo Volatile >> > > Here's a general question to the JDS folks -- is it worth making any of > these header directories Public at all? It seems that pretty much the only > way people know where these things are is through pkg-config(1). Or are > these names, complete with version numbers, stable enough that it's what > people actually code to? Given the rather expanded range of version number across the various modules, I think using pkg-config(1) is definitely the recommended way of accessing these headers directories. Do you recommend we remove all the directories from the interface table and rely on the stability of .pc files to access these path? > For that matter, are the version numbers of the > .pc files stable at all? > Yes. I believe so. The version number are also part of the name of the .pc file. For example, glibmm-2.4.pc is the one for glibmm. Thanks, -Ghee > Danek > From Ghee.Teo@sun.com Tue Feb 5 08:52:04 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m15Gq3V5028546 for ; Tue, 5 Feb 2008 08:52:04 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m15Gpuer000478; Wed, 6 Feb 2008 00:52:02 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVR00H0PYUP6L00@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Feb 2008 08:52:01 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVR00FJCYUONE40@nwk-avmta-2.sfbay.sun.com>; Tue, 05 Feb 2008 08:52:00 -0800 (PST) Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m15GpxZ0024454; Tue, 05 Feb 2008 16:51:59 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00801YPRLO00@fe-emea-10.sun.com> (original mail from Ghee.Teo@Sun.COM) ; Tue, 05 Feb 2008 16:51:59 +0000 (GMT) Received: from [129.156.226.231] by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR009UGYUNGK00@fe-emea-10.sun.com>; Tue, 05 Feb 2008 16:51:59 +0000 (GMT) Date: Tue, 05 Feb 2008 16:51:34 +0000 From: Ghee Teo Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080205152701.GE28799@zruty.sfbay.sun.com> Sender: Ghee.Teo@sun.com To: Danek Duvall Cc: "simon.zheng@sun.com" , Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Reply-to: Ghee.Teo@sun.com Message-id: <47A89416.30600@sun.com> Organization: Sun Microsystems Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <20080205152701.GE28799@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1292 Danek Duvall wrote: > On Tue, Feb 05, 2008 at 06:19:56PM +0800, simon.zheng@sun.com wrote: > > >> Danek Duvall wrote: >> >> >>>> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >>>> >>> What goes here and why is it Public? >>> >> Gtkmm or other libraries needs this program to generate gtkmm-style source >> code, that is, from "*.ccg" to "*.cc" and "*.hg" to "*.h". I want to keep >> it public. >> > > Could you explain the code generation more? What are .ccg and .hg files? > I thought one just wrote in C++ to use the *mm versions of the gnome > libraries. > > Is this program invoked from the library code itself, or is it something > that people would use directly in a Makefile? > Reading a bit more into gmmproc, I think this is used by gtkmm instead of application developers which write C++ program to use thse libraries. gmmproc is part of glibmm and it is built and installed so that gtkmm can then use it to generate the C++ wrapper for gtk++. So it is arguable private but keeping it on glibmm and install it, only one copy is need to be maintained for the whole stack. more infor here: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html -Ghee > THanks, > Danek > From John.Plocher@sun.com Wed Feb 6 09:14:01 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16HE1pX011747 for ; Wed, 6 Feb 2008 09:14:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m16HE09K013281; Wed, 6 Feb 2008 09:14:00 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVT00H0TUJC7X00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Feb 2008 09:14:00 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVT00G4MUJBRM10@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Feb 2008 09:13:59 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16HDwPK012190; Wed, 06 Feb 2008 09:13:58 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00C01UFRC500@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Wed, 06 Feb 2008 09:13:58 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT008QDUJ3MHA0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 09:13:51 -0800 (PST) Date: Wed, 06 Feb 2008 09:13:49 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <1202185683.1528.70.camel@localhost> Sender: John.Plocher@sun.com To: laca@sun.com Cc: lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47A9EACD.4050802@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1163 Laszlo (Laca) Peter wrote: > Given that these are c++ libs, is it acceptable to ship > duplicate copies built with g++ (/usr/sfw/bin/g++) and if > so, where should they be installed? The problem is that there is no ABI standard for g++, so you would need to create and ship different versions of the libs for each and every release of g++ that [exists, we ship, we choose to support, pick one]. When you consider that the g++ ABI has frequently changed in patches and bugfixes for g++, this doesn't leave us with any reasonable choice - we can't do "all", tying *every* C++ app to the g++ patch release schedule doesn't scale, and if we only pick one or a couple of releases, they will tend to be not the ones customers want...) As long as someone has all the source code for libs and apps (aka gentoo), the g++ abi doesn't really matter, as it is possible to compile a consistent set of things. Once you provide precompiled g++ libs, you are tied to a specific patch level of the g++ compiler tools suite. Because of this, we have historically said no to non-studio C++ libs, unless those libs only exported "C" ABIs (via extern "C" constructs). -John From sacadmin Wed Feb 6 09:14:04 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16HE4BQ011765 for ; Wed, 6 Feb 2008 09:14:04 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16HE4eY021389 for ; Wed, 6 Feb 2008 09:14:04 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16HDwtx012189 for ; Wed, 6 Feb 2008 09:13:59 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00C01UFRC500@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed, 06 Feb 2008 09:13:58 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT008QDUJ3MHA0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 09:13:51 -0800 (PST) Date: Wed, 06 Feb 2008 09:13:49 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <1202185683.1528.70.camel@localhost> Sender: John.Plocher@sun.com To: laca@sun.com Cc: lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47A9EACD.4050802@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1163 Laszlo (Laca) Peter wrote: > Given that these are c++ libs, is it acceptable to ship > duplicate copies built with g++ (/usr/sfw/bin/g++) and if > so, where should they be installed? The problem is that there is no ABI standard for g++, so you would need to create and ship different versions of the libs for each and every release of g++ that [exists, we ship, we choose to support, pick one]. When you consider that the g++ ABI has frequently changed in patches and bugfixes for g++, this doesn't leave us with any reasonable choice - we can't do "all", tying *every* C++ app to the g++ patch release schedule doesn't scale, and if we only pick one or a couple of releases, they will tend to be not the ones customers want...) As long as someone has all the source code for libs and apps (aka gentoo), the g++ abi doesn't really matter, as it is possible to compile a consistent set of things. Once you provide precompiled g++ libs, you are tied to a specific patch level of the g++ compiler tools suite. Because of this, we have historically said no to non-studio C++ libs, unless those libs only exported "C" ABIs (via extern "C" constructs). -John From sacadmin Wed Feb 6 09:39:07 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16Hd7Cg013815 for ; Wed, 6 Feb 2008 09:39:07 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m16Hd7ua265228; Wed, 6 Feb 2008 17:39:07 GMT Message-ID: <47A9EFA4.8000509@Sun.COM> Date: Wed, 06 Feb 2008 09:34:28 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: John Plocher CC: laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> In-Reply-To: <47A9EACD.4050802@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1778 John Plocher wrote: > Laszlo (Laca) Peter wrote: >> Given that these are c++ libs, is it acceptable to ship >> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >> so, where should they be installed? > > The problem is that there is no ABI standard for g++, > so you would need to create and ship different versions > of the libs for each and every release of g++ that [exists, > we ship, we choose to support, pick one]. When you > consider that the g++ ABI has frequently changed in patches > and bugfixes for g++, this doesn't leave us with any > reasonable choice - we can't do "all", tying *every* C++ > app to the g++ patch release schedule doesn't scale, and > if we only pick one or a couple of releases, they will > tend to be not the ones customers want...) > > As long as someone has all the source code for libs and apps > (aka gentoo), the g++ abi doesn't really matter, as it is > possible to compile a consistent set of things. Once you > provide precompiled g++ libs, you are tied to a specific > patch level of the g++ compiler tools suite. > > Because of this, we have historically said no to non-studio > C++ libs, unless those libs only exported "C" ABIs (via > extern "C" constructs). > > -John > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org The answer here seems to be that since we build Solaris with two compilers, stdio and (optionally)gcc, we could choose to ship C++ libs like this compiled w/ each one of these compilers. The ABI of the libraries would/could change everytime we rev'd the compilers - but we don't do that except in a minor release. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Wed Feb 6 09:39:15 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16HdF20013831 for ; Wed, 6 Feb 2008 09:39:15 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m16HdA2N032538; Wed, 6 Feb 2008 10:39:12 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVT0080RVPAHQ00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 09:39:10 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVT0008YVP7J290@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 09:39:07 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m16Hd7ua265228; Wed, 06 Feb 2008 17:39:07 +0000 (GMT) Date: Wed, 06 Feb 2008 09:34:28 -0800 From: Bart Smaalders Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A9EACD.4050802@Sun.Com> To: John Plocher Cc: laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Message-id: <47A9EFA4.8000509@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1778 John Plocher wrote: > Laszlo (Laca) Peter wrote: >> Given that these are c++ libs, is it acceptable to ship >> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >> so, where should they be installed? > > The problem is that there is no ABI standard for g++, > so you would need to create and ship different versions > of the libs for each and every release of g++ that [exists, > we ship, we choose to support, pick one]. When you > consider that the g++ ABI has frequently changed in patches > and bugfixes for g++, this doesn't leave us with any > reasonable choice - we can't do "all", tying *every* C++ > app to the g++ patch release schedule doesn't scale, and > if we only pick one or a couple of releases, they will > tend to be not the ones customers want...) > > As long as someone has all the source code for libs and apps > (aka gentoo), the g++ abi doesn't really matter, as it is > possible to compile a consistent set of things. Once you > provide precompiled g++ libs, you are tied to a specific > patch level of the g++ compiler tools suite. > > Because of this, we have historically said no to non-studio > C++ libs, unless those libs only exported "C" ABIs (via > extern "C" constructs). > > -John > > _______________________________________________ > opensolaris-arc mailing list > opensolaris-arc@opensolaris.org The answer here seems to be that since we build Solaris with two compilers, stdio and (optionally)gcc, we could choose to ship C++ libs like this compiled w/ each one of these compilers. The ABI of the libraries would/could change everytime we rev'd the compilers - but we don't do that except in a minor release. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Wed Feb 6 09:42:19 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16HgJJe014077 for ; Wed, 6 Feb 2008 09:42:19 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16HgJAa038318 for ; Wed, 6 Feb 2008 09:42:19 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16HgDDo015647 for ; Wed, 6 Feb 2008 09:42:13 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00C01VQVM400@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed, 06 Feb 2008 09:42:13 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT00D8KVU5FW90@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 09:42:06 -0800 (PST) Date: Wed, 06 Feb 2008 09:42:05 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A7E83B.9020708@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Bart Smaalders Cc: laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev , Rod Evans Message-id: <47A9F16D.50609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A7E83B.9020708@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 517 Bart Smaalders wrote: > I suggest that we need a minimum of four directories: > (32, 64) x (gcc, studio). We should noodle out a design > (perhaps w/ help from the linker folks) that will find > the appropriate version of the C++ libraries needed. 64-bit gcc-built libraries would be useless until the SFW gcc/g++ is fixed to actually produce usable 64-bit linking flags. (Bugs 6623370 & 6223255.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Wed Feb 6 09:42:25 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16HgOUL014089 for ; Wed, 6 Feb 2008 09:42:24 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m16HfkUK007100; Thu, 7 Feb 2008 01:42:20 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVT00813VUFQU00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 09:42:15 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVT0003FVUEJAA0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 09:42:14 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16HgD0p028981; Wed, 06 Feb 2008 09:42:14 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00C01VQVM400@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Wed, 06 Feb 2008 09:42:13 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVT00D8KVU5FW90@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 09:42:06 -0800 (PST) Date: Wed, 06 Feb 2008 09:42:05 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A7E83B.9020708@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Bart Smaalders Cc: laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev , Rod Evans Message-id: <47A9F16D.50609@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A7E83B.9020708@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 517 Bart Smaalders wrote: > I suggest that we need a minimum of four directories: > (32, 64) x (gcc, studio). We should noodle out a design > (perhaps w/ help from the linker folks) that will find > the appropriate version of the C++ libraries needed. 64-bit gcc-built libraries would be useless until the SFW gcc/g++ is fixed to actually produce usable 64-bit linking flags. (Bugs 6623370 & 6223255.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Feb 6 11:13:09 2008 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16JD8Hh020680 for ; Wed, 6 Feb 2008 11:13:09 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m16JD5eo016672; Wed, 6 Feb 2008 19:13:05 GMT Message-Id: <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> From: Casper.Dik@sun.com To: Bart Smaalders cc: John Plocher , laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-Reply-To: <47A9EFA4.8000509@Sun.COM> References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47A9EFA4.8000509@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Feb 2008 20:13:05 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 516 >The answer here seems to be that since we build Solaris with >two compilers, stdio and (optionally)gcc, we could choose >to ship C++ libs like this compiled w/ each one of these >compilers. > >The ABI of the libraries would/could change everytime >we rev'd the compilers - but we don't do that except >in a minor release. We should also make clear that Sun's compilers do better when it comes to an ABI guarantee (we had far fewer changes and compatibility options over the last 10 years than g++ did) Casper From casper@holland.sun.com Wed Feb 6 11:13:16 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16JDFiQ020693 for ; Wed, 6 Feb 2008 11:13:16 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16JCt6M017222; Wed, 6 Feb 2008 19:13:15 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVU00L01022NY00@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Feb 2008 11:13:14 -0800 (PST) Received: from dm-holland-02.uk.sun.com ([129.156.101.225]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVU00GSS020RT90@nwk-avmta-2.sfbay.sun.com>; Wed, 06 Feb 2008 11:13:13 -0800 (PST) Received: from holland (room101.Holland.Sun.COM [10.16.117.40]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id m16JD5eo016672; Wed, 06 Feb 2008 19:13:05 +0000 (GMT) Date: Wed, 06 Feb 2008 20:13:05 +0100 From: Casper.Dik@sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A9EFA4.8000509@Sun.COM> Sender: casper@holland.sun.com To: Bart Smaalders Cc: John Plocher , laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Message-id: <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47A9EFA4.8000509@Sun.COM> Status: RO Content-Length: 516 >The answer here seems to be that since we build Solaris with >two compilers, stdio and (optionally)gcc, we could choose >to ship C++ libs like this compiled w/ each one of these >compilers. > >The ABI of the libraries would/could change everytime >we rev'd the compilers - but we don't do that except >in a minor release. We should also make clear that Sun's compilers do better when it comes to an ABI guarantee (we had far fewer changes and compatibility options over the last 10 years than g++ did) Casper From sacadmin Wed Feb 6 11:17:34 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16JHY0N020795 for ; Wed, 6 Feb 2008 11:17:34 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16JHYZA047692 for ; Wed, 6 Feb 2008 11:17:34 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16JHTfd028224 for ; Wed, 6 Feb 2008 11:17:29 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00K01ZXY0X00@fe-sfbay-09.sun.com> (original mail from Terrence.Miller@Sun.COM) for LSARC@sac.sfbay.sun.com; Wed, 06 Feb 2008 11:17:29 -0800 (PST) Received: from [129.146.86.55] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVU00FAJ092AUE0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 11:17:27 -0800 (PST) Date: Wed, 06 Feb 2008 11:17:26 -0800 From: Terrence Miller Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A9EACD.4050802@Sun.Com> Sender: Terrence.Miller@sun.com To: John Plocher Cc: laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Reply-to: Terrence.Miller@sun.com Message-id: <47AA07C6.80804@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_eq7bJMr46evGaXS0jM2Rug)" References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2415 This is a multi-part message in MIME format. --Boundary_(ID_eq7bJMr46evGaXS0jM2Rug) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Using libraries with a C++ interface is even more dangerous than John describes. If the include file which specifies the library interface is written to allow inlining of function calls, programs using the library become sensitive to minute details of the library implementation (even if the compiler is unchanged). IMO any C++ interface to a shared library should be consolidation private so that library and clients can be recompiled together. Having C wrappers for the library entry points (that we ship) would satisfy that requirement. John Plocher wrote: > Laszlo (Laca) Peter wrote: >> Given that these are c++ libs, is it acceptable to ship >> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >> so, where should they be installed? > > The problem is that there is no ABI standard for g++, > so you would need to create and ship different versions > of the libs for each and every release of g++ that [exists, > we ship, we choose to support, pick one]. When you > consider that the g++ ABI has frequently changed in patches > and bugfixes for g++, this doesn't leave us with any > reasonable choice - we can't do "all", tying *every* C++ > app to the g++ patch release schedule doesn't scale, and > if we only pick one or a couple of releases, they will > tend to be not the ones customers want...) > > As long as someone has all the source code for libs and apps > (aka gentoo), the g++ abi doesn't really matter, as it is > possible to compile a consistent set of things. Once you > provide precompiled g++ libs, you are tied to a specific > patch level of the g++ compiler tools suite. > > Because of this, we have historically said no to non-studio > C++ libs, unless those libs only exported "C" ABIs (via > extern "C" constructs). > > -John > --Boundary_(ID_eq7bJMr46evGaXS0jM2Rug) Content-type: text/x-vcard; name=Terrence.Miller.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Terrence.Miller.vcf begin:vcard fn:Terrence Miller n:Miller;Terrence adr:16 Network Circle;;UMPK-303;Menlo Park,;CA;94025;USA email;internet:terrence.miller@sun.com tel;work:650-786-9192 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_eq7bJMr46evGaXS0jM2Rug)-- From Terrence.Miller@sun.com Wed Feb 6 11:17:37 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16JHaxr020799 for ; Wed, 6 Feb 2008 11:17:36 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m16JHUgQ018664; Wed, 6 Feb 2008 19:17:35 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVU00G2H099XH00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 11:17:33 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVU00FCX095HG10@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 11:17:29 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m16JHTvo012516; Wed, 06 Feb 2008 11:17:29 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVT00K01ZXY0X00@fe-sfbay-09.sun.com> (original mail from Terrence.Miller@Sun.COM); Wed, 06 Feb 2008 11:17:29 -0800 (PST) Received: from [129.146.86.55] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVU00FAJ092AUE0@fe-sfbay-09.sun.com>; Wed, 06 Feb 2008 11:17:27 -0800 (PST) Date: Wed, 06 Feb 2008 11:17:26 -0800 From: Terrence Miller Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A9EACD.4050802@Sun.Com> Sender: Terrence.Miller@sun.com To: John Plocher Cc: laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Reply-to: Terrence.Miller@sun.com Message-id: <47AA07C6.80804@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_AuS6laZodI4uvT3M1uQRPA)" X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070802) Status: RO Content-Length: 2415 This is a multi-part message in MIME format. --Boundary_(ID_AuS6laZodI4uvT3M1uQRPA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Using libraries with a C++ interface is even more dangerous than John describes. If the include file which specifies the library interface is written to allow inlining of function calls, programs using the library become sensitive to minute details of the library implementation (even if the compiler is unchanged). IMO any C++ interface to a shared library should be consolidation private so that library and clients can be recompiled together. Having C wrappers for the library entry points (that we ship) would satisfy that requirement. John Plocher wrote: > Laszlo (Laca) Peter wrote: >> Given that these are c++ libs, is it acceptable to ship >> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >> so, where should they be installed? > > The problem is that there is no ABI standard for g++, > so you would need to create and ship different versions > of the libs for each and every release of g++ that [exists, > we ship, we choose to support, pick one]. When you > consider that the g++ ABI has frequently changed in patches > and bugfixes for g++, this doesn't leave us with any > reasonable choice - we can't do "all", tying *every* C++ > app to the g++ patch release schedule doesn't scale, and > if we only pick one or a couple of releases, they will > tend to be not the ones customers want...) > > As long as someone has all the source code for libs and apps > (aka gentoo), the g++ abi doesn't really matter, as it is > possible to compile a consistent set of things. Once you > provide precompiled g++ libs, you are tied to a specific > patch level of the g++ compiler tools suite. > > Because of this, we have historically said no to non-studio > C++ libs, unless those libs only exported "C" ABIs (via > extern "C" constructs). > > -John > --Boundary_(ID_AuS6laZodI4uvT3M1uQRPA) Content-type: text/x-vcard; name=Terrence.Miller.vcf; charset=utf-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=Terrence.Miller.vcf begin:vcard fn:Terrence Miller n:Miller;Terrence adr:16 Network Circle;;UMPK-303;Menlo Park,;CA;94025;USA email;internet:terrence.miller@sun.com tel;work:650-786-9192 x-mozilla-html:FALSE version:2.1 end:vcard --Boundary_(ID_AuS6laZodI4uvT3M1uQRPA)-- From sacadmin Wed Feb 6 13:43:33 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16LhXYg027357 for ; Wed, 6 Feb 2008 13:43:33 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m16LhWpZ274810; Wed, 6 Feb 2008 21:43:32 GMT Message-ID: <47AA28EB.4080301@Sun.COM> Date: Wed, 06 Feb 2008 13:38:51 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: John Plocher , laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47A9EFA4.8000509@Sun.COM> <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> In-Reply-To: <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 777 Casper.Dik@Sun.COM wrote: > >> The answer here seems to be that since we build Solaris with >> two compilers, stdio and (optionally)gcc, we could choose >> to ship C++ libs like this compiled w/ each one of these >> compilers. >> >> The ABI of the libraries would/could change everytime >> we rev'd the compilers - but we don't do that except >> in a minor release. > > > We should also make clear that Sun's compilers do better when it comes > to an ABI guarantee (we had far fewer changes and compatibility options > over the last 10 years than g++ did) > > Casper > So w/ studio you might have to recompile every minor release; with gcc it's more certain. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Wed Feb 6 13:43:42 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m16LhfVn027369 for ; Wed, 6 Feb 2008 13:43:42 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m16LhY8r011740; Thu, 7 Feb 2008 05:43:36 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVU0071J70NF000@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 13:43:35 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVU00FL770LHSB0@nwk-avmta-1.sfbay.Sun.COM>; Wed, 06 Feb 2008 13:43:33 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m16LhWpZ274810; Wed, 06 Feb 2008 21:43:32 +0000 (GMT) Date: Wed, 06 Feb 2008 13:38:51 -0800 From: Bart Smaalders Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> To: Casper.Dik@sun.com Cc: John Plocher , laca@sun.com, jds-dev , Shiying Irene Huang , lsarc-ext , LSARC@sac.sfbay.sun.com Message-id: <47AA28EB.4080301@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47A9EFA4.8000509@Sun.COM> <200802061913.m16JD5eo016672@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 777 Casper.Dik@Sun.COM wrote: > >> The answer here seems to be that since we build Solaris with >> two compilers, stdio and (optionally)gcc, we could choose >> to ship C++ libs like this compiled w/ each one of these >> compilers. >> >> The ABI of the libraries would/could change everytime >> we rev'd the compilers - but we don't do that except >> in a minor release. > > > We should also make clear that Sun's compilers do better when it comes > to an ABI guarantee (we had far fewer changes and compatibility options > over the last 10 years than g++ did) > > Casper > So w/ studio you might have to recompile every minor release; with gcc it's more certain. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Darren.Kenny@sun.com Thu Feb 7 00:58:45 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m178wiGh018386 for ; Thu, 7 Feb 2008 00:58:45 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m178wgOe019857; Thu, 7 Feb 2008 16:58:43 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0080V29UF800@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 00:58:42 -0800 (PST) Received: from gmp-eb-mail-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00CR629SWSA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 00:58:41 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m178wenl007281; Thu, 07 Feb 2008 08:58:40 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00L011YWAY00@fe-emea-09.sun.com> (original mail from Darren.Kenny@Sun.COM); Thu, 07 Feb 2008 08:58:40 +0000 (GMT) Received: from [129.156.226.149] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00J6O29MAPA0@fe-emea-09.sun.com>; Thu, 07 Feb 2008 08:58:35 +0000 (GMT) Date: Thu, 07 Feb 2008 08:58:21 +0000 From: Darren Kenny Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AA07C6.80804@Sun.COM> Sender: Darren.Kenny@sun.com To: Terrence.Miller@sun.com Cc: John Plocher , laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47AAC82D.9060000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 3140 The main benefit of having libraries in a public location is that people will use them - while these libraries are dependencies of some apps, they are also very useful for more rapid desktop development - making something Consolidation Private really defeats this purpose. I think we need to get away from the idea of Consolidations a bit, since OpenSolaris really breaks down these barriers and I think it would be pity to raise them again out there. We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this works for people out of the box, clearly stating the C++ compiler to use. Is there some way that the compiler and linker could work together to flag a possible issue at run-time of the app and libs version of C++ compiler don't match? It would actually be easier if the C++ compiler was simply there by default after installation so that there is less risk of someone installing the "wrong one"... At least with OpenSolaris using IPS and a "blessed repository" it's more likely that everything could be synchronised since if you bump the version of the compiler all libraries could be rebuilt with the version too - this is actually more difficult for Solaris... Darren. Terrence Miller wrote: > Using libraries with a C++ interface is even more dangerous than John > describes. If the include file which specifies the library interface is > written to allow inlining of function calls, programs using the library > become sensitive to minute details of the library implementation (even > if the compiler is unchanged). > > IMO any C++ interface to a shared library should be consolidation > private so that library and clients can be recompiled together. > Having C wrappers for the library entry points (that we ship) would > satisfy that requirement. > > > John Plocher wrote: >> Laszlo (Laca) Peter wrote: >>> Given that these are c++ libs, is it acceptable to ship >>> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >>> so, where should they be installed? >> The problem is that there is no ABI standard for g++, >> so you would need to create and ship different versions >> of the libs for each and every release of g++ that [exists, >> we ship, we choose to support, pick one]. When you >> consider that the g++ ABI has frequently changed in patches >> and bugfixes for g++, this doesn't leave us with any >> reasonable choice - we can't do "all", tying *every* C++ >> app to the g++ patch release schedule doesn't scale, and >> if we only pick one or a couple of releases, they will >> tend to be not the ones customers want...) >> >> As long as someone has all the source code for libs and apps >> (aka gentoo), the g++ abi doesn't really matter, as it is >> possible to compile a consistent set of things. Once you >> provide precompiled g++ libs, you are tied to a specific >> patch level of the g++ compiler tools suite. >> >> Because of this, we have historically said no to non-studio >> C++ libs, unless those libs only exported "C" ABIs (via >> extern "C" constructs). >> >> -John >> From sacadmin Thu Feb 7 00:58:46 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m178wkop018390 for ; Thu, 7 Feb 2008 00:58:46 -0800 (PST) Received: from gmp-eb-mail-2.sun.com (gmp-eb-mail-2.EU.Sun.COM [192.18.6.24]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m178wjGg052160 for ; Thu, 7 Feb 2008 00:58:46 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m178wec8007280 for ; Thu, 7 Feb 2008 08:58:40 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00L011YWAY00@fe-emea-09.sun.com> (original mail from Darren.Kenny@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 08:58:40 +0000 (GMT) Received: from [129.156.226.149] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00J6O29MAPA0@fe-emea-09.sun.com>; Thu, 07 Feb 2008 08:58:35 +0000 (GMT) Date: Thu, 07 Feb 2008 08:58:21 +0000 From: Darren Kenny Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AA07C6.80804@Sun.COM> Sender: Darren.Kenny@sun.com To: Terrence.Miller@sun.com Cc: John Plocher , laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47AAC82D.9060000@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (X11/20080128) Status: RO Content-Length: 3140 The main benefit of having libraries in a public location is that people will use them - while these libraries are dependencies of some apps, they are also very useful for more rapid desktop development - making something Consolidation Private really defeats this purpose. I think we need to get away from the idea of Consolidations a bit, since OpenSolaris really breaks down these barriers and I think it would be pity to raise them again out there. We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this works for people out of the box, clearly stating the C++ compiler to use. Is there some way that the compiler and linker could work together to flag a possible issue at run-time of the app and libs version of C++ compiler don't match? It would actually be easier if the C++ compiler was simply there by default after installation so that there is less risk of someone installing the "wrong one"... At least with OpenSolaris using IPS and a "blessed repository" it's more likely that everything could be synchronised since if you bump the version of the compiler all libraries could be rebuilt with the version too - this is actually more difficult for Solaris... Darren. Terrence Miller wrote: > Using libraries with a C++ interface is even more dangerous than John > describes. If the include file which specifies the library interface is > written to allow inlining of function calls, programs using the library > become sensitive to minute details of the library implementation (even > if the compiler is unchanged). > > IMO any C++ interface to a shared library should be consolidation > private so that library and clients can be recompiled together. > Having C wrappers for the library entry points (that we ship) would > satisfy that requirement. > > > John Plocher wrote: >> Laszlo (Laca) Peter wrote: >>> Given that these are c++ libs, is it acceptable to ship >>> duplicate copies built with g++ (/usr/sfw/bin/g++) and if >>> so, where should they be installed? >> The problem is that there is no ABI standard for g++, >> so you would need to create and ship different versions >> of the libs for each and every release of g++ that [exists, >> we ship, we choose to support, pick one]. When you >> consider that the g++ ABI has frequently changed in patches >> and bugfixes for g++, this doesn't leave us with any >> reasonable choice - we can't do "all", tying *every* C++ >> app to the g++ patch release schedule doesn't scale, and >> if we only pick one or a couple of releases, they will >> tend to be not the ones customers want...) >> >> As long as someone has all the source code for libs and apps >> (aka gentoo), the g++ abi doesn't really matter, as it is >> possible to compile a consistent set of things. Once you >> provide precompiled g++ libs, you are tied to a specific >> patch level of the g++ compiler tools suite. >> >> Because of this, we have historically said no to non-studio >> C++ libs, unless those libs only exported "C" ABIs (via >> extern "C" constructs). >> >> -John >> From Simon.Zheng@sun.com Thu Feb 7 04:39:49 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17Cdmse022909 for ; Thu, 7 Feb 2008 04:39:49 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17CdWBF028557; Thu, 7 Feb 2008 12:39:47 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00M03CI9I100@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 04:39:45 -0800 (PST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00I98CI8VX60@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 04:39:45 -0800 (PST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m17CdnxH015978; Thu, 07 Feb 2008 12:39:49 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JVV00301CD3U400@mail-apac.sun.com> (original mail from Simon.Zheng@Sun.COM); Thu, 07 Feb 2008 20:39:43 +0800 (SGT) Received: from [192.168.0.105] ([125.33.142.228]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JVV0034WCI1MJNE@mail-apac.sun.com>; Thu, 07 Feb 2008 20:39:43 +0800 (SGT) Date: Thu, 07 Feb 2008 20:40:06 +0800 From: "simon.zheng" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A88606.8080905@sun.com> Sender: Simon.Zheng@sun.com To: Brian Cameron , Danek Duvall Cc: Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <47AAFC26.8010801@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) Status: RO Content-Length: 1465 Brian Cameron wrote: > > Simon: > >>>> /usr/lib/libglibmm_generate_extra_defs-2.4.so Volatile >>>> >>> >>> Does anyone ever need to link to this library specifically? This seems >>> like a very private implementation detail that should either be a >>> filter >>> library or simply not exist on Solaris. >>> >> Fine. I would like let it private. > > I am confused. You agree to change the interface classification without > answering Danek's questions. I think it would be useful to explain how > this library is used so we can make sure we set its interface stability > level properly. Brian and Danek, This library is used to build the "generate_extra_defs" utility executable, which is a tool to generate the signals and properties .defs files. The .defs file are text file, in a lisp format, that describe the API of a C library, including its objects (GObjects, widgets, interfaces, boxed-types and plain structs), functions, enums, signals and properties. Among them, "generate_extra_defs" executable is responsible for generating part of the signals and properties .defs files. Eventally, .defs files and gmmproc work together to generate real .cc and .h source files. More info is http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html Therefore, in one word, this library should be the same stability level as "gmmproc", I want to keep them in public. Thanks, -Simon > > Brian > From sacadmin Thu Feb 7 08:06:07 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17G670t027158 for ; Thu, 7 Feb 2008 08:06:07 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17G67xf020776 for ; Thu, 7 Feb 2008 08:06:07 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17G62S2025183 for ; Thu, 7 Feb 2008 08:06:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00I01LYXSX00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 08:06:02 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00ADIM1T0640@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 08:05:53 -0800 (PST) Date: Thu, 07 Feb 2008 08:05:52 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AAC82D.9060000@Sun.COM> Sender: John.Plocher@sun.com To: Darren Kenny Cc: Terrence.Miller@sun.com, laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47AB2C60.7050208@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1495 Darren Kenny wrote: > The main benefit of having libraries in a public location is that people will > use them - while these libraries are dependencies of some apps, they are also > very useful for more rapid desktop development - making something Consolidation > Private really defeats this purpose. +1 > I think we need to get away from the idea of Consolidations a bit, since > OpenSolaris really breaks down these barriers and I think it would be pity to > raise them again out there. +0 - IMO, we need to drastically shrink the sizes of our consolidations - and raise the number of them. For example, each and every FOSS thing should be its own consolidation - it delivers as a unit, it has its own versioning, etc. IPS and repositories are tools that let us do that. > > We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for > Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this > works for people out of the box, clearly stating the C++ compiler to use. That's why the rule is "if you do this, you must use studio". > Is there some way that the compiler and linker could work together to flag a > possible issue at run-time of the app and libs version of C++ compiler don't match? They do - the error is usually "Symbol not found" :-) > It would actually be easier if the C++ compiler was simply there by default > after installation so that there is less risk of someone installing the "wrong > one"... +1000 -John From John.Plocher@sun.com Thu Feb 7 08:06:14 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17G6EBw027170 for ; Thu, 7 Feb 2008 08:06:14 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17G6D1C027710; Thu, 7 Feb 2008 08:06:13 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0020BM296W00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 08:06:09 -0800 (PST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV001KGM22IN00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 08:06:02 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17G6296000571; Thu, 07 Feb 2008 08:06:02 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00I01LYXSX00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 07 Feb 2008 08:06:02 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00ADIM1T0640@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 08:05:53 -0800 (PST) Date: Thu, 07 Feb 2008 08:05:52 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AAC82D.9060000@Sun.COM> Sender: John.Plocher@sun.com To: Darren Kenny Cc: Terrence.Miller@sun.com, laca@sun.com, lsarc-ext , LSARC@sac.sfbay.sun.com, Shiying Irene Huang , jds-dev Message-id: <47AB2C60.7050208@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1495 Darren Kenny wrote: > The main benefit of having libraries in a public location is that people will > use them - while these libraries are dependencies of some apps, they are also > very useful for more rapid desktop development - making something Consolidation > Private really defeats this purpose. +1 > I think we need to get away from the idea of Consolidations a bit, since > OpenSolaris really breaks down these barriers and I think it would be pity to > raise them again out there. +0 - IMO, we need to drastically shrink the sizes of our consolidations - and raise the number of them. For example, each and every FOSS thing should be its own consolidation - it delivers as a unit, it has its own versioning, etc. IPS and repositories are tools that let us do that. > > We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for > Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this > works for people out of the box, clearly stating the C++ compiler to use. That's why the rule is "if you do this, you must use studio". > Is there some way that the compiler and linker could work together to flag a > possible issue at run-time of the app and libs version of C++ compiler don't match? They do - the error is usually "Symbol not found" :-) > It would actually be easier if the C++ compiler was simply there by default > after installation so that there is less risk of someone installing the "wrong > one"... +1000 -John From sacadmin Thu Feb 7 08:28:15 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17GSFdN028502 for ; Thu, 7 Feb 2008 08:28:15 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17GSFQP288511; Thu, 7 Feb 2008 16:28:15 GMT Message-ID: <47AB3086.2070001@Sun.COM> Date: Thu, 07 Feb 2008 08:23:34 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: Darren Kenny CC: Terrence.Miller@sun.com, laca@sun.com, jds-dev , John Plocher , lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> In-Reply-To: <47AAC82D.9060000@Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 3013 Darren Kenny wrote: > The main benefit of having libraries in a public location is that people will > use them - while these libraries are dependencies of some apps, they are also > very useful for more rapid desktop development - making something Consolidation > Private really defeats this purpose. > Agreed.... but we need to actually figure out how to deliver a working build 85 if code in the SFW gate is built against build 84 JDS bits, and JDS revs and delivers an incompatible version of a needed library in build 85. Cross consolidation flag days are a real PITA right now. > I think we need to get away from the idea of Consolidations a bit, since > OpenSolaris really breaks down these barriers and I think it would be pity to > raise them again out there. > > We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for > Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this > works for people out of the box, clearly stating the C++ compiler to use. Here's the problem: some open source C++ will only compile w/ gcc. Do we prevent people from compiling any apps that link w/ that library with Studio? Or do we ship two versions of each C++ library? If we ship both, where do they go? How does the linker choose the right one? > > Is there some way that the compiler and linker could work together to flag a > possible issue at run-time of the app and libs version of C++ compiler don't match? > Generally, it doesn't link at all; the error messages aren't obvious, however. > It would actually be easier if the C++ compiler was simply there by default > after installation so that there is less risk of someone installing the "wrong > one"... > g++ is; we're working on CC. IPS will help a lot, since you'll be able to grab the right compilers and install them on a system w/ pkg install gcc This doesn't deal with the problem of different apps needing different revs of the compilers, but at least that's a little rarer problem aside from things such as wine. > At least with OpenSolaris using IPS and a "blessed repository" it's more likely > that everything could be synchronised since if you bump the version of the > compiler all libraries could be rebuilt with the version too - this is actually > more difficult for Solaris... > > Darren. The issue of reving the compilers is that we use them to build the kernel, and bugs in kernels are generally mnoticable, aggravating and serious. The amount of testing required to shake out new versions of compilers for ON is substantial; we've never been able to build a working kernel w/ an FCS compiler that I know of.... we always have needed various bugs fixed... The implication that the repository would handle the synchronization problem pre-supposes that everything in the repository is built at once, or at least staged. This is not at all necessarily the case.... - Bart Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Thu Feb 7 08:28:26 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17GSPjn028514 for ; Thu, 7 Feb 2008 08:28:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17GS4KF014402; Thu, 7 Feb 2008 16:28:19 GMT Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0072LN34GA00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 08:28:16 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV004RUN33UP60@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 08:28:16 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17GSFQP288511; Thu, 07 Feb 2008 16:28:15 +0000 (GMT) Date: Thu, 07 Feb 2008 08:23:34 -0800 From: Bart Smaalders Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AAC82D.9060000@Sun.COM> To: Darren Kenny Cc: Terrence.Miller@sun.com, laca@sun.com, jds-dev , John Plocher , lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB3086.2070001@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 3013 Darren Kenny wrote: > The main benefit of having libraries in a public location is that people will > use them - while these libraries are dependencies of some apps, they are also > very useful for more rapid desktop development - making something Consolidation > Private really defeats this purpose. > Agreed.... but we need to actually figure out how to deliver a working build 85 if code in the SFW gate is built against build 84 JDS bits, and JDS revs and delivers an incompatible version of a needed library in build 85. Cross consolidation flag days are a real PITA right now. > I think we need to get away from the idea of Consolidations a bit, since > OpenSolaris really breaks down these barriers and I think it would be pity to > raise them again out there. > > We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for > Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this > works for people out of the box, clearly stating the C++ compiler to use. Here's the problem: some open source C++ will only compile w/ gcc. Do we prevent people from compiling any apps that link w/ that library with Studio? Or do we ship two versions of each C++ library? If we ship both, where do they go? How does the linker choose the right one? > > Is there some way that the compiler and linker could work together to flag a > possible issue at run-time of the app and libs version of C++ compiler don't match? > Generally, it doesn't link at all; the error messages aren't obvious, however. > It would actually be easier if the C++ compiler was simply there by default > after installation so that there is less risk of someone installing the "wrong > one"... > g++ is; we're working on CC. IPS will help a lot, since you'll be able to grab the right compilers and install them on a system w/ pkg install gcc This doesn't deal with the problem of different apps needing different revs of the compilers, but at least that's a little rarer problem aside from things such as wine. > At least with OpenSolaris using IPS and a "blessed repository" it's more likely > that everything could be synchronised since if you bump the version of the > compiler all libraries could be rebuilt with the version too - this is actually > more difficult for Solaris... > > Darren. The issue of reving the compilers is that we use them to build the kernel, and bugs in kernels are generally mnoticable, aggravating and serious. The amount of testing required to shake out new versions of compilers for ON is substantial; we've never been able to build a working kernel w/ an FCS compiler that I know of.... we always have needed various bugs fixed... The implication that the repository would handle the synchronization problem pre-supposes that everything in the repository is built at once, or at least staged. This is not at all necessarily the case.... - Bart Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Thu Feb 7 08:33:52 2008 Received: from zion.sfbay.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17GXq17028567 for ; Thu, 7 Feb 2008 08:33:52 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17GXqhs288558; Thu, 7 Feb 2008 16:33:52 GMT Message-ID: <47AB31D7.1060900@Sun.COM> Date: Thu, 07 Feb 2008 08:29:11 -0800 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.6 (X11/20070924) MIME-Version: 1.0 To: John Plocher CC: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> In-Reply-To: <47AB2C60.7050208@Sun.Com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1260 John Plocher wrote: > Darren Kenny wrote: ... >> I think we need to get away from the idea of Consolidations a bit, since >> OpenSolaris really breaks down these barriers and I think it would be pity to >> raise them again out there. > > +0 - IMO, we need to drastically shrink the sizes of our consolidations - and > raise the number of them. For example, each and every FOSS thing should be > its own consolidation - it delivers as a unit, it has its own versioning, etc. > IPS and repositories are tools that let us do that. > Today, a consolidation delivers separately to the WOS/dock/repository. Please describe how a FOSSS project would deliver a new, incompatible version of a library used by multiple FOSS "things". Take as an example rev'ing OpenSSL. >> We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for >> Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this >> works for people out of the box, clearly stating the C++ compiler to use. > > That's why the rule is "if you do this, you must use studio". > Which of course precludes software that will only compile w/ g++. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From bart.smaalders@sun.com Thu Feb 7 08:34:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17GXxaD028579 for ; Thu, 7 Feb 2008 08:34:00 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m17GXXl5018578; Fri, 8 Feb 2008 00:33:54 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00405NCHJI00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 08:33:53 -0800 (PST) Received: from zion.sfbay.sun.com ([129.146.17.75]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV001QSNCGI420@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 08:33:52 -0800 (PST) Received: from [129.146.228.109] (cyber.SFBay.Sun.COM [129.146.228.109]) by zion.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17GXqhs288558; Thu, 07 Feb 2008 16:33:52 +0000 (GMT) Date: Thu, 07 Feb 2008 08:29:11 -0800 From: Bart Smaalders Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB2C60.7050208@Sun.Com> To: John Plocher Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB31D7.1060900@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20070924) Status: RO Content-Length: 1260 John Plocher wrote: > Darren Kenny wrote: ... >> I think we need to get away from the idea of Consolidations a bit, since >> OpenSolaris really breaks down these barriers and I think it would be pity to >> raise them again out there. > > +0 - IMO, we need to drastically shrink the sizes of our consolidations - and > raise the number of them. For example, each and every FOSS thing should be > its own consolidation - it delivers as a unit, it has its own versioning, etc. > IPS and repositories are tools that let us do that. > Today, a consolidation delivers separately to the WOS/dock/repository. Please describe how a FOSSS project would deliver a new, incompatible version of a library used by multiple FOSS "things". Take as an example rev'ing OpenSSL. >> We really need to get C++ sorted for Solaris/OpenSolaris - we all use a CBE for >> Solaris - and OpenSolaris AFAIK - could we not just ensure that at least this >> works for people out of the box, clearly stating the C++ compiler to use. > > That's why the rule is "if you do this, you must use studio". > Which of course precludes software that will only compile w/ g++. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From sacadmin Thu Feb 7 09:15:19 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17HFJko029250 for ; Thu, 7 Feb 2008 09:15:19 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m17HFIYm025141; Thu, 7 Feb 2008 11:15:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m17HFI58025140; Thu, 7 Feb 2008 11:15:18 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Feb 2008 11:15:18 -0600 From: Nicolas Williams To: John Plocher Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] Message-ID: <20080207171518.GX19708@Sun.COM> References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47AB2C60.7050208@Sun.Com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 949 On Thu, Feb 07, 2008 at 08:05:52AM -0800, John Plocher wrote: > Darren Kenny wrote: > > The main benefit of having libraries in a public location is that people will > > use them - while these libraries are dependencies of some apps, they are also > > very useful for more rapid desktop development - making something Consolidation > > Private really defeats this purpose. > > +1 +1 > > I think we need to get away from the idea of Consolidations a bit, since > > OpenSolaris really breaks down these barriers and I think it would be pity to > > raise them again out there. > > +0 - IMO, we need to drastically shrink the sizes of our consolidations - and > raise the number of them. For example, each and every FOSS thing should be > its own consolidation - it delivers as a unit, it has its own versioning, etc. > IPS and repositories are tools that let us do that. How is the SFW consolidation not an aggregate of FOSS mini-consolidations? From Nicolas.Williams@sun.com Thu Feb 7 09:15:31 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17HFUuo029262 for ; Thu, 7 Feb 2008 09:15:30 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m17HFLjI006210; Fri, 8 Feb 2008 01:15:24 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00809P9K6Q00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 09:15:20 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV001O5P9JI450@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 09:15:19 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m17HFIYm025141; Thu, 07 Feb 2008 11:15:18 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m17HFI58025140; Thu, 07 Feb 2008 11:15:18 -0600 (CST) Date: Thu, 07 Feb 2008 11:15:18 -0600 From: Nicolas Williams Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB2C60.7050208@Sun.Com> To: John Plocher Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <20080207171518.GX19708@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 949 On Thu, Feb 07, 2008 at 08:05:52AM -0800, John Plocher wrote: > Darren Kenny wrote: > > The main benefit of having libraries in a public location is that people will > > use them - while these libraries are dependencies of some apps, they are also > > very useful for more rapid desktop development - making something Consolidation > > Private really defeats this purpose. > > +1 +1 > > I think we need to get away from the idea of Consolidations a bit, since > > OpenSolaris really breaks down these barriers and I think it would be pity to > > raise them again out there. > > +0 - IMO, we need to drastically shrink the sizes of our consolidations - and > raise the number of them. For example, each and every FOSS thing should be > its own consolidation - it delivers as a unit, it has its own versioning, etc. > IPS and repositories are tools that let us do that. How is the SFW consolidation not an aggregate of FOSS mini-consolidations? From sacadmin Thu Feb 7 09:58:32 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17HwW6N001977 for ; Thu, 7 Feb 2008 09:58:32 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17HwVCg028553 for ; Thu, 7 Feb 2008 09:58:31 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17HwQ3W010315 for ; Thu, 7 Feb 2008 09:58:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00H01R842Z00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 09:58:26 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00DGFR9E57A0@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 09:58:26 -0800 (PST) Date: Thu, 07 Feb 2008 09:58:25 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB31D7.1060900@Sun.COM> Sender: John.Plocher@sun.com To: Bart Smaalders Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB46C1.2020505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1373 Bart Smaalders wrote: > Please describe how a FOSSS project would deliver a new, incompatible > version of a library used by multiple FOSS "things". Take as an example > rev'ing OpenSSL. Designing on-the-fly: The OpenSSL team would deliver a new versioned binary package into the "bleeding edge" repository. The ON consolidation's security team would react to the availability of a new OpenSSL by installing it, testing it, fixing the interactions that broke with it, etc, iterating as needed with bug reports to the OpenSSL team and a stream of updated bleeding edge versions. Once things "worked", a new version of ON would be pushed to the bleeding edge repository and the recipe for building an ON-based distro would be updated to reflect the new OpenSSL version. This is effectively what is done today at the source code level, but with OpenSSL copy/pasted into ON's source tree. It also may be that this fits better with middleware and leaf-node packages as found in SFW rather than ON. Think sizeof(debian) -vs- sizeof(SFW).... > Which of course precludes software that will only compile w/ g++. Even if we delivered a g++ version of the lib, it would only work if you also used only and exactly the same version of g++ to compile your application - if the compilers were different, it would be just as if we never shipped the library in the first place. From John.Plocher@sun.com Thu Feb 7 09:58:34 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17HwX6n001981 for ; Thu, 7 Feb 2008 09:58:33 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17HwQHk025587; Thu, 7 Feb 2008 17:58:30 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0020HR9HJP00@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 10:58:29 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00FDCR9F00A0@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 10:58:27 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17HwQ0R014452; Thu, 07 Feb 2008 09:58:26 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00H01R842Z00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 07 Feb 2008 09:58:26 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00DGFR9E57A0@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 09:58:26 -0800 (PST) Date: Thu, 07 Feb 2008 09:58:25 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB31D7.1060900@Sun.COM> Sender: John.Plocher@sun.com To: Bart Smaalders Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB46C1.2020505@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 1373 Bart Smaalders wrote: > Please describe how a FOSSS project would deliver a new, incompatible > version of a library used by multiple FOSS "things". Take as an example > rev'ing OpenSSL. Designing on-the-fly: The OpenSSL team would deliver a new versioned binary package into the "bleeding edge" repository. The ON consolidation's security team would react to the availability of a new OpenSSL by installing it, testing it, fixing the interactions that broke with it, etc, iterating as needed with bug reports to the OpenSSL team and a stream of updated bleeding edge versions. Once things "worked", a new version of ON would be pushed to the bleeding edge repository and the recipe for building an ON-based distro would be updated to reflect the new OpenSSL version. This is effectively what is done today at the source code level, but with OpenSSL copy/pasted into ON's source tree. It also may be that this fits better with middleware and leaf-node packages as found in SFW rather than ON. Think sizeof(debian) -vs- sizeof(SFW).... > Which of course precludes software that will only compile w/ g++. Even if we delivered a g++ version of the lib, it would only work if you also used only and exactly the same version of g++ to compile your application - if the compilers were different, it would be just as if we never shipped the library in the first place. From John.Plocher@sun.com Thu Feb 7 10:30:27 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17IUQ9T004151 for ; Thu, 7 Feb 2008 10:30:26 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m17IUN8O006419; Fri, 8 Feb 2008 02:30:25 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0050TSQO2Y00@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 11:30:24 -0700 (MST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00FHASQN00C0@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 11:30:24 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17IUNsf014523; Thu, 07 Feb 2008 10:30:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00601QV4UT00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 07 Feb 2008 10:30:23 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00DKBSQMVY90@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 10:30:22 -0800 (PST) Date: Thu, 07 Feb 2008 10:30:21 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080207171518.GX19708@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB4E3D.2070103@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 769 Nicolas Williams wrote: > How is the SFW consolidation not an aggregate of FOSS mini-consolidations? At this point, it *seems* to be little more than an artifact of how we used to do things in Solaris when we built DVDs in vinyl binders, rather than something much more dynamic like debian or blastwave. In my mind, it boils down to a question of why we would require, say, the source for Firefox to be copied from the upstream community to a SFW source tree, compiled by SFW maintainers, and pushed to a repository, rather than having the firefox community itself create ips packages and push them out directly? On the other hand, if you equate debian with sfw (as both being consolidations of FOSS stuff), then there is probably little to no difference. -John From sacadmin Thu Feb 7 10:30:29 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17IUTLE004156 for ; Thu, 7 Feb 2008 10:30:29 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17IUSpS041488 for ; Thu, 7 Feb 2008 10:30:28 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17IUNRq018386 for ; Thu, 7 Feb 2008 10:30:23 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00601QV4UT00@fe-sfbay-09.sun.com> (original mail from John.Plocher@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 10:30:23 -0800 (PST) Received: from wp668.SFBay.Sun.COM ([129.146.226.219]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00DKBSQMVY90@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 10:30:22 -0800 (PST) Date: Thu, 07 Feb 2008 10:30:21 -0800 From: John Plocher Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080207171518.GX19708@Sun.COM> Sender: John.Plocher@sun.com To: Nicolas Williams Cc: Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB4E3D.2070103@Sun.Com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) Status: RO Content-Length: 769 Nicolas Williams wrote: > How is the SFW consolidation not an aggregate of FOSS mini-consolidations? At this point, it *seems* to be little more than an artifact of how we used to do things in Solaris when we built DVDs in vinyl binders, rather than something much more dynamic like debian or blastwave. In my mind, it boils down to a question of why we would require, say, the source for Firefox to be copied from the upstream community to a SFW source tree, compiled by SFW maintainers, and pushed to a repository, rather than having the firefox community itself create ips packages and push them out directly? On the other hand, if you equate debian with sfw (as both being consolidations of FOSS stuff), then there is probably little to no difference. -John From Alan.Coopersmith@sun.com Thu Feb 7 10:42:25 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17IgPom005391 for ; Thu, 7 Feb 2008 10:42:25 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17IgOhS044305; Thu, 7 Feb 2008 11:42:24 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00G05TAN7D00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 10:42:23 -0800 (PST) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV001XPTALI190@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 10:42:21 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17IgLjH016950; Thu, 07 Feb 2008 10:42:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00601T6WJS00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Thu, 07 Feb 2008 10:42:21 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00D7XTADVYG0@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 10:42:14 -0800 (PST) Date: Thu, 07 Feb 2008 10:42:13 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB4E3D.2070103@Sun.Com> Sender: Alan.Coopersmith@sun.com To: John Plocher Cc: Nicolas Williams , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB5105.10701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 928 John Plocher wrote: > In my mind, it boils down to a question of why we would require, say, the > source for Firefox to be copied from the upstream community to a SFW source > tree, compiled by SFW maintainers, and pushed to a repository, rather than > having the firefox community itself create ips packages and push them out > directly? Because the firefox community has no interest in doing so. The only reason Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because Sun's browser team downloads the source, builds them, and pushes them back to the community. I would not expect most open source communities to have any interest in producing packages for every single distro & packaging system - there's just too many to have it done by anyone but the people who care about each distro. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Feb 7 10:42:26 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17IgQKd005397 for ; Thu, 7 Feb 2008 10:42:26 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17IgQvg055288 for ; Thu, 7 Feb 2008 10:42:26 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17IgLK1016949 for ; Thu, 7 Feb 2008 10:42:21 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00601T6WJS00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 10:42:21 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00D7XTADVYG0@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 10:42:14 -0800 (PST) Date: Thu, 07 Feb 2008 10:42:13 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB4E3D.2070103@Sun.Com> Sender: Alan.Coopersmith@sun.com To: John Plocher Cc: Nicolas Williams , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB5105.10701@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 928 John Plocher wrote: > In my mind, it boils down to a question of why we would require, say, the > source for Firefox to be copied from the upstream community to a SFW source > tree, compiled by SFW maintainers, and pushed to a repository, rather than > having the firefox community itself create ips packages and push them out > directly? Because the firefox community has no interest in doing so. The only reason Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because Sun's browser team downloads the source, builds them, and pushes them back to the community. I would not expect most open source communities to have any interest in producing packages for every single distro & packaging system - there's just too many to have it done by anyone but the people who care about each distro. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From danek.duvall@sun.com Thu Feb 7 10:57:55 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17Ivt9s006208 for ; Thu, 7 Feb 2008 10:57:55 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17IvsOW050214; Thu, 7 Feb 2008 11:57:54 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00H01U0IFW00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 10:57:54 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV001FEU0FIGC0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 10:57:51 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17Ivnhk062026; Thu, 07 Feb 2008 10:57:49 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17IvnbX029321; Thu, 07 Feb 2008 10:57:49 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m17IvnF8029320; Thu, 07 Feb 2008 10:57:49 -0800 (PST) Date: Thu, 07 Feb 2008 10:57:48 -0800 From: Danek Duvall Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AAFC26.8010801@sun.com> To: "simon.zheng" Cc: Brian Cameron , Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <20080207185748.GI22027@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 565 On Thu, Feb 07, 2008 at 08:40:06PM +0800, simon.zheng wrote: > This library is used to build the "generate_extra_defs" utility executable, > which is a tool to generate the signals and properties .defs files. > > [ ... ] > > Eventally, .defs files and gmmproc work together to generate real .cc and > .h source files. More info is > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html This is incredibly confusing. That page doesn't really explain much except how to copy another project that's already done all the work. From what I read in the gtkmm docs, it looks like the gmmproc executable is Status: RO used to convert .hg and .ccg files into .h and .cc files, which are then compiled. That would indicate that gmmproc should be in /usr/bin, and be at a high stability level. But I see no documentation on generate_extra_defs, or on libglibmm_generate_extra_defs-2.4, so I still don't have a handle on what they're for. Is generate_extra_defs something you'd put in a makefile to run over the .hg and .ccg files to generate a .defs file? Is libglibmm_generate_extra_defs-2.4 something that's only ever linked to by generate_extra_defs, or do user applications link to it as well? Danek From danek.duvall@sun.com Thu Feb 7 11:06:57 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17J6v0g007400 for ; Thu, 7 Feb 2008 11:06:57 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17J6uPe054529; Thu, 7 Feb 2008 12:06:57 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00D0TUFKJR00@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 11:06:57 -0800 (PST) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00D2MUFDFF10@nwk-avmta-2.sfbay.sun.com>; Thu, 07 Feb 2008 11:06:49 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17J6mXZ008402; Thu, 07 Feb 2008 11:06:48 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m17J6mhT029447; Thu, 07 Feb 2008 11:06:48 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m17J6li9029446; Thu, 07 Feb 2008 11:06:47 -0800 (PST) Date: Thu, 07 Feb 2008 11:06:47 -0800 From: Danek Duvall Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47A891EB.8080505@sun.com> To: Ghee Teo Cc: Shi-Ying Irene Huang , LSARC-ext@sun.com, jds-dev@sun.com Message-id: <20080207190647.GJ22027@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A891EB.8080505@sun.com> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 3097 On Tue, Feb 05, 2008 at 04:42:19PM +0000, Ghee Teo wrote: >> Given that these libraries are themselves built on top of the C versions >> of the same libraries to which we're assigning a "Committed" label, I'd >> expect that these were at least Uncommitted, if not Committed. > > Uncommitted for gtkmm, glibmm and cairomm. Okay. >> Are these libraries correctly versioned as described in the libraries best >> practices document? > These libraries versioned are created by the maintainer of the software. > For example, even if the version of glib that we built the sample on is > 2.14.x, it still produces the version library of libglibmm-2.4. So we > can't change these without the risk of being incompatable. I'm talking about the internal versioning and scoping that should be done for all libraries delivered on Solaris. This helps a great deal when different symbols in a library have different stability levels -- you can make symbols completely private to the library, or you can stick them in buckets which are advertised as public, or private, but usable with caution. Doing this work isn't very difficult either to do or to maintain, but upstream might be happy to accept the finished work. It looks like even the main gtk library isn't versioned, though, so I doubt it'll happen for this, either. >>> /usr/lib/glibmm-2.4/proc/gmmproc Volatile >> >> What goes here and why is it Public? > > Simon answered this as to why he want this to be public. If it is public, > it should be moved to /usr/bin I would think. Agreed. >>> /usr/lib/glibmm-2.4/include/glibmmconfig.h Volatile >>> /usr/lib/sigc++-2.0/include/sigc++config.h Volatile >>> >> >> Why do we have Public header files under /usr/lib? Such things tend to be >> Private. > > The above two header files will not be delivered, they are private, > required only to build the libraries. Okay, good. >>> /usr/include/glibmm-2.4/glibmm Volatile >>> Header files directory >>> > This one must have. It contains all the header fiels for glibmm Sure, but why are they in a subdirectory of glibmm-2.4? None of the other include directories are like that. >>> /usr/include/glibmm-2.4/glibmm_generate_extra_defs Volatile >>> Header files directory > > This one can possibly removed from interface table. It doesn't seems to > do much at the moment. Okay. > Given the rather expanded range of version number across the various > modules, I think using pkg-config(1) is definitely the recommended way of > accessing these headers directories. Do you recommend we remove all the > directories from the interface table and rely on the stability of .pc > files to access these path? It's not my recommendation to make. I'm asking *you*. >> For that matter, are the version numbers of the >> .pc files stable at all? > > Yes. I believe so. The version number are also part of the name of the > .pc file. For example, glibmm-2.4.pc is the one for glibmm. Okay. Thanks, Danek From sacadmin Thu Feb 7 11:49:36 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17JnZrm008799 for ; Thu, 7 Feb 2008 11:49:36 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m17JnZoI025267; Thu, 7 Feb 2008 13:49:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m17JnZ20025266; Thu, 7 Feb 2008 13:49:35 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Feb 2008 13:49:35 -0600 From: Nicolas Williams To: John Plocher Cc: Bart Smaalders , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] Message-ID: <20080207194935.GC19708@Sun.COM> References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> <47AB46C1.2020505@Sun.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47AB46C1.2020505@Sun.Com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1470 On Thu, Feb 07, 2008 at 09:58:25AM -0800, John Plocher wrote: > Bart Smaalders wrote: > > Please describe how a FOSSS project would deliver a new, incompatible > > version of a library used by multiple FOSS "things". Take as an example > > rev'ing OpenSSL. > > Designing on-the-fly: > > The OpenSSL team would deliver a new versioned binary package > into the "bleeding edge" repository. > > The ON consolidation's security team would react to the availability > of a new OpenSSL by installing it, testing it, fixing the interactions > that broke with it, etc, iterating as needed with bug reports to the > [...] It'd be better if the OpenSSL community had interface and release taxonomies roughly compatible with ours, very rare major releases (in the sense of breaking compatibility), and, where the had to do major releases, if they took some pains to avoid DLL hell. But they don't. What's my point? I'm not sure. I'd like us to work on ways to diminish DLL hell without that meaning either that many communities must synchronize release trains nor that distros must do all the work that you describe, nor that we can't ship multiple versions of things like OpenSSL, nor that we must lag years behind comunities that do major releases often. I'm sure we can't do anything comprehensive here though, so maybe I'm just carping. But if anyone wants to discuss doing something, anything, about this, then feel free to contact me about it off-list. Nico -- From Nicolas.Williams@sun.com Thu Feb 7 11:49:43 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17JnhLe008811 for ; Thu, 7 Feb 2008 11:49:43 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17Jncrf003986; Thu, 7 Feb 2008 11:49:38 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00L0BWEPKX00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 11:49:37 -0800 (PST) Received: from binky.Central.Sun.COM ([129.153.128.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00K91WEOGX40@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 11:49:36 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m17JnZoI025267; Thu, 07 Feb 2008 13:49:35 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m17JnZ20025266; Thu, 07 Feb 2008 13:49:35 -0600 (CST) Date: Thu, 07 Feb 2008 13:49:35 -0600 From: Nicolas Williams Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB46C1.2020505@Sun.Com> To: John Plocher Cc: Bart Smaalders , Darren Kenny , laca@sun.com, jds-dev , terrence.miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <20080207194935.GC19708@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> <47AB46C1.2020505@Sun.Com> X-Authentication-warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1470 On Thu, Feb 07, 2008 at 09:58:25AM -0800, John Plocher wrote: > Bart Smaalders wrote: > > Please describe how a FOSSS project would deliver a new, incompatible > > version of a library used by multiple FOSS "things". Take as an example > > rev'ing OpenSSL. > > Designing on-the-fly: > > The OpenSSL team would deliver a new versioned binary package > into the "bleeding edge" repository. > > The ON consolidation's security team would react to the availability > of a new OpenSSL by installing it, testing it, fixing the interactions > that broke with it, etc, iterating as needed with bug reports to the > [...] It'd be better if the OpenSSL community had interface and release taxonomies roughly compatible with ours, very rare major releases (in the sense of breaking compatibility), and, where the had to do major releases, if they took some pains to avoid DLL hell. But they don't. What's my point? I'm not sure. I'd like us to work on ways to diminish DLL hell without that meaning either that many communities must synchronize release trains nor that distros must do all the work that you describe, nor that we can't ship multiple versions of things like OpenSSL, nor that we must lag years behind comunities that do major releases often. I'm sure we can't do anything comprehensive here though, so maybe I'm just carping. But if anyone wants to discuss doing something, anything, about this, then feel free to contact me about it off-list. Nico -- From sacadmin Thu Feb 7 12:58:14 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17KwEXg011052 for ; Thu, 7 Feb 2008 12:58:14 -0800 (PST) Received: from gmp-eb-mail-1.sun.com (gmp-eb-mail-1.EU.Sun.COM [192.18.6.21]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17KwDHm006679 for ; Thu, 7 Feb 2008 12:58:14 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe1.eu.sun.com [192.18.6.10]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17Kw75h004980 for ; Thu, 7 Feb 2008 20:58:08 GMT Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00L01ZKCO600@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 20:58:07 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00F8MZKUFN30@fe-emea-09.sun.com>; Thu, 07 Feb 2008 20:58:07 +0000 (GMT) Date: Thu, 07 Feb 2008 20:58:06 +0000 From: Darren J Moffat Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB46C1.2020505@Sun.Com> Sender: Darren.Moffat@sun.com To: John Plocher Cc: Bart Smaalders , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB70DE.6080600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> <47AB46C1.2020505@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1944 John Plocher wrote: > Bart Smaalders wrote: >> Please describe how a FOSSS project would deliver a new, incompatible >> version of a library used by multiple FOSS "things". Take as an example >> rev'ing OpenSSL. > > Designing on-the-fly: > > The OpenSSL team would deliver a new versioned binary package > into the "bleeding edge" repository. I know you mean that as an example but OpenSSL is probably the single worst example you could have picked :-) > The ON consolidation's security team would react to the availability > of a new OpenSSL by installing it, testing it, fixing the interactions > that broke with it, etc, iterating as needed with bug reports to the > OpenSSL team and a stream of updated bleeding edge versions. Once > things "worked", a new version of ON would be pushed to the bleeding > edge repository and the recipe for building an ON-based distro would > be updated to reflect the new OpenSSL version. > > This is effectively what is done today at the source code level, > but with OpenSSL copy/pasted into ON's source tree. Actually not quite. OpenSSL is compiled 5 times in ON: i386, amd64, sparcv7, sparcv9, stand for wanboot. The standard OpenSSL makefiles don't provide the ability to that. OpenSSL in ON isn't yet vanilla OpenSSL from openssl.org (it is patched - less that it used to be but it is patch) because of its use by wanboot in the pre kernel environment. Until that can be resolved by updating wanboot to do something else or by having some other consolidation build OpenSSL suitable for wanboot (which I doubt since it is tricky enough to do in ON never mind out of it) OpenSSL can't be anywhere but ON. I wish (oh how I wish!) that I had done thinks differently when I was advising the wanboot team and when I first integrated OpenSSL (but that was all prior to the rampup of the SFW consolidation). Anyway none of this is really relevant to this case. -- Darren J Moffat From Darren.Moffat@sun.com Thu Feb 7 12:58:17 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17KwGV8011056 for ; Thu, 7 Feb 2008 12:58:17 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m17Kw1dr005664; Fri, 8 Feb 2008 04:58:13 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0040BZKXRE00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 12:58:09 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV002C8ZKWSQA0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 12:58:09 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17Kw7xv004981; Thu, 07 Feb 2008 20:58:07 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00L01ZKCO600@fe-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM); Thu, 07 Feb 2008 20:58:07 +0000 (GMT) Received: from [129.156.173.21] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00F8MZKUFN30@fe-emea-09.sun.com>; Thu, 07 Feb 2008 20:58:07 +0000 (GMT) Date: Thu, 07 Feb 2008 20:58:06 +0000 From: Darren J Moffat Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB46C1.2020505@Sun.Com> Sender: Darren.Moffat@sun.com To: John Plocher Cc: Bart Smaalders , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB70DE.6080600@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <47AB31D7.1060900@Sun.COM> <47AB46C1.2020505@Sun.Com> User-Agent: Thunderbird 2.0.0.6 (X11/20080102) Status: RO Content-Length: 1944 John Plocher wrote: > Bart Smaalders wrote: >> Please describe how a FOSSS project would deliver a new, incompatible >> version of a library used by multiple FOSS "things". Take as an example >> rev'ing OpenSSL. > > Designing on-the-fly: > > The OpenSSL team would deliver a new versioned binary package > into the "bleeding edge" repository. I know you mean that as an example but OpenSSL is probably the single worst example you could have picked :-) > The ON consolidation's security team would react to the availability > of a new OpenSSL by installing it, testing it, fixing the interactions > that broke with it, etc, iterating as needed with bug reports to the > OpenSSL team and a stream of updated bleeding edge versions. Once > things "worked", a new version of ON would be pushed to the bleeding > edge repository and the recipe for building an ON-based distro would > be updated to reflect the new OpenSSL version. > > This is effectively what is done today at the source code level, > but with OpenSSL copy/pasted into ON's source tree. Actually not quite. OpenSSL is compiled 5 times in ON: i386, amd64, sparcv7, sparcv9, stand for wanboot. The standard OpenSSL makefiles don't provide the ability to that. OpenSSL in ON isn't yet vanilla OpenSSL from openssl.org (it is patched - less that it used to be but it is patch) because of its use by wanboot in the pre kernel environment. Until that can be resolved by updating wanboot to do something else or by having some other consolidation build OpenSSL suitable for wanboot (which I doubt since it is tricky enough to do in ON never mind out of it) OpenSSL can't be anywhere but ON. I wish (oh how I wish!) that I had done thinks differently when I was advising the wanboot team and when I first integrated OpenSSL (but that was all prior to the rampup of the SFW consolidation). Anyway none of this is really relevant to this case. -- Darren J Moffat From sacadmin Thu Feb 7 13:00:03 2008 Received: from dm-sfbay-02.sfbay.sun.com (dm-sfbay-02 [129.146.11.31]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17L03rF011228 for ; Thu, 7 Feb 2008 13:00:03 -0800 (PST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17L03G9010812 for ; Thu, 7 Feb 2008 13:00:03 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m17L024n029596 for ; Thu, 7 Feb 2008 21:00:02 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00401V9ZE900@mail-amer.sun.com> (original mail from Dana.Myers@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 14:00:02 -0700 (MST) Received: from [192.168.0.103] (c-67-180-22-170.hsd1.ca.comcast.net [67.180.22.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV001MEZNUM970@mail-amer.sun.com>; Thu, 07 Feb 2008 13:59:55 -0700 (MST) Date: Thu, 07 Feb 2008 12:59:33 -0800 From: "Dana H. Myers" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB5105.10701@sun.com> Sender: Dana.Myers@sun.com To: Alan Coopersmith Cc: John Plocher , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7135.3030008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 789 Alan Coopersmith wrote: > John Plocher wrote: > >> In my mind, it boils down to a question of why we would require, say, the >> source for Firefox to be copied from the upstream community to a SFW source >> tree, compiled by SFW maintainers, and pushed to a repository, rather than >> having the firefox community itself create ips packages and push them out >> directly? >> > > Because the firefox community has no interest in doing so. The only reason > Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because > Sun's browser team downloads the source, builds them, and pushes them back > to the community. > Perhaps this is a naive question, but doesn't that mean the Sun browser team is functioning as a de facto member of the Firefox community? Dana From Dana.Myers@sun.com Thu Feb 7 13:00:07 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17L079P011261 for ; Thu, 7 Feb 2008 13:00:07 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m17L06ok021428; Thu, 7 Feb 2008 13:00:07 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV0040PZO6YF00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 13:00:06 -0800 (PST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV00262ZO3SQB0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 07 Feb 2008 13:00:03 -0800 (PST) Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m17L02wq006634; Thu, 07 Feb 2008 21:00:02 +0000 (GMT) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00401V9ZE900@mail-amer.sun.com> (original mail from Dana.Myers@Sun.COM); Thu, 07 Feb 2008 14:00:02 -0700 (MST) Received: from [192.168.0.103] (c-67-180-22-170.hsd1.ca.comcast.net [67.180.22.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV001MEZNUM970@mail-amer.sun.com>; Thu, 07 Feb 2008 13:59:55 -0700 (MST) Date: Thu, 07 Feb 2008 12:59:33 -0800 From: "Dana H. Myers" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB5105.10701@sun.com> Sender: Dana.Myers@sun.com To: Alan Coopersmith Cc: John Plocher , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7135.3030008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 789 Alan Coopersmith wrote: > John Plocher wrote: > >> In my mind, it boils down to a question of why we would require, say, the >> source for Firefox to be copied from the upstream community to a SFW source >> tree, compiled by SFW maintainers, and pushed to a repository, rather than >> having the firefox community itself create ips packages and push them out >> directly? >> > > Because the firefox community has no interest in doing so. The only reason > Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because > Sun's browser team downloads the source, builds them, and pushes them back > to the community. > Perhaps this is a naive question, but doesn't that mean the Sun browser team is functioning as a de facto member of the Firefox community? Dana From sacadmin Thu Feb 7 13:03:55 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17L3tfV011553 for ; Thu, 7 Feb 2008 13:03:55 -0800 (PST) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17L3thS010048 for ; Thu, 7 Feb 2008 13:03:55 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17L3odm005530 for ; Thu, 7 Feb 2008 13:03:50 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00201ZPG9R00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 13:03:49 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00HHNZTXJI40@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 13:03:34 -0800 (PST) Date: Thu, 07 Feb 2008 13:03:33 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB7135.3030008@sun.com> Sender: Alan.Coopersmith@sun.com To: "Dana H. Myers" Cc: John Plocher , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7225.8060400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> <47AB7135.3030008@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1160 Dana H. Myers wrote: > Alan Coopersmith wrote: >> John Plocher wrote: >> >>> In my mind, it boils down to a question of why we would require, say, >>> the >>> source for Firefox to be copied from the upstream community to a SFW >>> source >>> tree, compiled by SFW maintainers, and pushed to a repository, rather >>> than >>> having the firefox community itself create ips packages and push them >>> out >>> directly? >>> >> >> Because the firefox community has no interest in doing so. The only >> reason >> Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because >> Sun's browser team downloads the source, builds them, and pushes them >> back >> to the community. >> > Perhaps this is a naive question, but doesn't that mean the Sun browser > team is functioning > as a de facto member of the Firefox community? Yes, and for some communities, Sun is actively participating, but we're not going to do that for all of the communities around the hundreds or someday even thousands of open source modules we ship. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Thu Feb 7 13:03:56 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17L3tMm011552 for ; Thu, 7 Feb 2008 13:03:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17L3msg019576; Thu, 7 Feb 2008 21:03:54 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVV00G0LZUFM700@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 14:03:51 -0700 (MST) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVV0084VZUE2FA0@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 14:03:50 -0700 (MST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17L3oai007854; Thu, 07 Feb 2008 13:03:50 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVV00201ZPG9R00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM); Thu, 07 Feb 2008 13:03:49 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVV00HHNZTXJI40@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 13:03:34 -0800 (PST) Date: Thu, 07 Feb 2008 13:03:33 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB7135.3030008@sun.com> Sender: Alan.Coopersmith@sun.com To: "Dana H. Myers" Cc: John Plocher , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7225.8060400@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 X-Enigmail-Version: 0.95.1 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> <47AB7135.3030008@sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1160 Dana H. Myers wrote: > Alan Coopersmith wrote: >> John Plocher wrote: >> >>> In my mind, it boils down to a question of why we would require, say, >>> the >>> source for Firefox to be copied from the upstream community to a SFW >>> source >>> tree, compiled by SFW maintainers, and pushed to a repository, rather >>> than >>> having the firefox community itself create ips packages and push them >>> out >>> directly? >>> >> >> Because the firefox community has no interest in doing so. The only >> reason >> Solaris or OpenSolaris builds of firefox appear on Mozilla.org is because >> Sun's browser team downloads the source, builds them, and pushes them >> back >> to the community. >> > Perhaps this is a naive question, but doesn't that mean the Sun browser > team is functioning > as a de facto member of the Firefox community? Yes, and for some communities, Sun is actively participating, but we're not going to do that for all of the communities around the hundreds or someday even thousands of open source modules we ship. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Feb 7 13:30:02 2008 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17LU2oD012252 for ; Thu, 7 Feb 2008 13:30:02 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id m17LU1jU014082; Thu, 7 Feb 2008 15:30:01 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id m17LU103014081; Thu, 7 Feb 2008 15:30:01 -0600 (CST) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 7 Feb 2008 15:30:01 -0600 From: Nicolas Williams To: Alan Coopersmith Cc: "Dana H. Myers" , Darren Kenny , laca@sun.com, jds-dev , John Plocher , Terrence.Miller@sun.com, Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] Message-ID: <20080207213001.GL19708@Sun.COM> References: <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> <47AB7135.3030008@sun.com> <47AB7225.8060400@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47AB7225.8060400@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 781 On Thu, Feb 07, 2008 at 01:03:33PM -0800, Alan Coopersmith wrote: > Dana H. Myers wrote: > > Perhaps this is a naive question, but doesn't that mean the Sun > > browser team is functioning as a de facto member of the Firefox > > community? > > Yes, and for some communities, Sun is actively participating, but > we're not going to do that for all of the communities around the > hundreds or someday even thousands of open source modules we ship. One might think that the browser, of all things, would be sufficiently important that we'd be active participants in that community. I know, this is not architecture (except in so far as being active participants can improve the architecture), and borders on the not appropriate for lsarc-ext (which is why I dropped it). Nico -- From sacadmin Thu Feb 7 13:39:27 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17LdRrj012952 for ; Thu, 7 Feb 2008 13:39:27 -0800 (PST) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17LdRXe030937 for ; Thu, 7 Feb 2008 13:39:27 -0800 (PST) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m17LdMi0011917 for ; Thu, 7 Feb 2008 13:39:22 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVW0020118QBD00@fe-sfbay-09.sun.com> (original mail from Alan.Coopersmith@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 13:39:22 -0800 (PST) Received: from [129.146.108.211] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVW00HQ31HCX150@fe-sfbay-09.sun.com>; Thu, 07 Feb 2008 13:39:13 -0800 (PST) Date: Thu, 07 Feb 2008 13:39:12 -0800 From: Alan Coopersmith Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080207213001.GL19708@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Nicolas Williams Cc: "Dana H. Myers" , Darren Kenny , laca@sun.com, jds-dev , John Plocher , Terrence.Miller@sun.com, Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7A80.40105@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.1 References: <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> <47AB7135.3030008@sun.com> <47AB7225.8060400@sun.com> <20080207213001.GL19708@Sun.COM> User-Agent: Thunderbird 2.0.0.6 (X11/20071203) Status: RO Content-Length: 1086 Nicolas Williams wrote: > On Thu, Feb 07, 2008 at 01:03:33PM -0800, Alan Coopersmith wrote: >> Dana H. Myers wrote: >>> Perhaps this is a naive question, but doesn't that mean the Sun >>> browser team is functioning as a de facto member of the Firefox >>> community? >> Yes, and for some communities, Sun is actively participating, but >> we're not going to do that for all of the communities around the >> hundreds or someday even thousands of open source modules we ship. > > One might think that the browser, of all things, would be sufficiently > important that we'd be active participants in that community. Right, which is why Firefox is a poor example, because we are doing that. We're not going to do that for all the GNU command line replacements for the standard Unix toolset, or many of the other things we put into SFW for convenience, but which aren't a strategic part of our OS. Firefox is the exception, where we're very involved, not the common case. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Thu Feb 7 13:41:17 2008 Received: from dm-sfbay-01.sfbay.sun.com (dm-sfbay-01 [129.145.155.118]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17LfHvC012965 for ; Thu, 7 Feb 2008 13:41:17 -0800 (PST) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17LfH9c032047 for ; Thu, 7 Feb 2008 13:41:17 -0800 (PST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m17LfHuN018175 for ; Thu, 7 Feb 2008 21:41:17 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVW000011BZ5200@mail-amer.sun.com> (original mail from Dana.Myers@Sun.COM) for LSARC@sac.sfbay.sun.com; Thu, 07 Feb 2008 14:41:17 -0700 (MST) Received: from [192.168.0.103] (c-67-180-22-170.hsd1.ca.comcast.net [67.180.22.170]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVW00B0N1K8IB80@mail-amer.sun.com>; Thu, 07 Feb 2008 14:40:57 -0700 (MST) Date: Thu, 07 Feb 2008 13:40:34 -0800 From: "Dana H. Myers" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080207213001.GL19708@Sun.COM> Sender: Dana.Myers@sun.com To: Nicolas Williams Cc: Alan Coopersmith , Darren Kenny , laca@sun.com, jds-dev , John Plocher , Terrence.Miller@sun.com, Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <47AB7AD2.2010902@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> <47AB5105.10701@sun.com> <47AB7135.3030008@sun.com> <47AB7225.8060400@sun.com> <20080207213001.GL19708@Sun.COM> User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) Status: RO Content-Length: 1367 Nicolas Williams wrote: > On Thu, Feb 07, 2008 at 01:03:33PM -0800, Alan Coopersmith wrote: > >> Dana H. Myers wrote: >> >>> Perhaps this is a naive question, but doesn't that mean the Sun >>> browser team is functioning as a de facto member of the Firefox >>> community? >>> >> Yes, and for some communities, Sun is actively participating, but >> we're not going to do that for all of the communities around the >> hundreds or someday even thousands of open source modules we ship. >> > > One might think that the browser, of all things, would be sufficiently > important that we'd be active participants in that community. > > I know, this is not architecture (except in so far as being active > participants can improve the architecture), and borders on the not > appropriate for lsarc-ext (which is why I dropped it). > What Nico said. Communities do what they have an interest in; if we/Sun have an interest in the Firefox community doing something they don't currently do, then we seem to have two choices - either directly participate in the Firefox community, or recruit the OpenSolaris community for participants in the Firefox community. If someone told the OpenSolaris community to produce a ARM build, we'd say "start a project, contribute, maintain it". We shouldn't expect anything different from other communities. Dana From sacadmin Thu Feb 7 14:12:26 2008 Received: from buye.red.iplanet.com (buye.red.iplanet.com [192.18.65.224]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17MCQm2014954 for ; Thu, 7 Feb 2008 14:12:26 -0800 (PST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m17MCQsg006882; Thu, 7 Feb 2008 14:12:26 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m17MCQm5006881; Thu, 7 Feb 2008 14:12:26 -0800 (PST) Date: Thu, 7 Feb 2008 14:12:26 -0800 From: Jyri Virkki To: John Plocher Cc: Nicolas Williams , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] Message-ID: <20080207221226.GF6789@sun.com> References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47AB4E3D.2070103@Sun.Com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1047 John Plocher wrote: > > In my mind, it boils down to a question of why we would require, say, the > source for Firefox to be copied from the upstream community to a SFW source > tree, compiled by SFW maintainers, and pushed to a repository, rather than > having the firefox community itself create ips packages and push them out > directly? We wouldn't but shouldn't expect it either. If in, say, debian I want the packaged browser I don't get it from firefox community directly, I get it from the debian package repository where it has been packaged by the corresponding debian package maintainer(s) http://packages.debian.org/etch/iceweasel > On the other hand, if you equate debian with sfw (as both being > consolidations > of FOSS stuff), then there is probably little to no difference. Major difference is I could (apt-get source iceweasel ; apt-get build-dep iceweasel) and build only what I care to build/work on. (Not sure what this has to do with LSARC/2008/074 anymore.) -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From jyri@buye.red.iplanet.com Thu Feb 7 14:12:38 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m17MCbIk014966 for ; Thu, 7 Feb 2008 14:12:37 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m17MCNwg020523; Thu, 7 Feb 2008 22:12:30 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JVW00L0F30STV00@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 15:12:28 -0700 (MST) Received: from buye.red.iplanet.com ([192.18.65.224]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JVW00LEI30QHI00@brm-avmta-1.central.sun.com>; Thu, 07 Feb 2008 15:12:26 -0700 (MST) Received: from buye.red.iplanet.com (localhost [127.0.0.1]) by buye.red.iplanet.com (8.13.7+Sun/8.13.7) with ESMTP id m17MCQsg006882; Thu, 07 Feb 2008 14:12:26 -0800 (PST) Received: (from jyri@localhost) by buye.red.iplanet.com (8.13.7+Sun/8.13.7/Submit) id m17MCQm5006881; Thu, 07 Feb 2008 14:12:26 -0800 (PST) Date: Thu, 07 Feb 2008 14:12:26 -0800 From: Jyri Virkki Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47AB4E3D.2070103@Sun.Com> To: John Plocher Cc: Nicolas Williams , Darren Kenny , laca@sun.com, jds-dev , Terrence.Miller@sun.com, lsarc-ext , Shiying Irene Huang , LSARC@sac.sfbay.sun.com Message-id: <20080207221226.GF6789@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <47A3D99A.7080201@sun.com> <1202185683.1528.70.camel@localhost> <47A9EACD.4050802@Sun.Com> <47AA07C6.80804@Sun.COM> <47AAC82D.9060000@Sun.COM> <47AB2C60.7050208@Sun.Com> <20080207171518.GX19708@Sun.COM> <47AB4E3D.2070103@Sun.Com> User-Agent: Mutt/1.5.11 Status: RO Content-Length: 1047 John Plocher wrote: > > In my mind, it boils down to a question of why we would require, say, the > source for Firefox to be copied from the upstream community to a SFW source > tree, compiled by SFW maintainers, and pushed to a repository, rather than > having the firefox community itself create ips packages and push them out > directly? We wouldn't but shouldn't expect it either. If in, say, debian I want the packaged browser I don't get it from firefox community directly, I get it from the debian package repository where it has been packaged by the corresponding debian package maintainer(s) http://packages.debian.org/etch/iceweasel > On the other hand, if you equate debian with sfw (as both being > consolidations > of FOSS stuff), then there is probably little to no difference. Major difference is I could (apt-get source iceweasel ; apt-get build-dep iceweasel) and build only what I care to build/work on. (Not sure what this has to do with LSARC/2008/074 anymore.) -- Jyri J. Virkki - jyri.virkki@sun.com - Sun Microsystems From Simon.Zheng@sun.com Sat Feb 9 20:48:56 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1A4mtY5025454 for ; Sat, 9 Feb 2008 20:48:56 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1A4mruw027995; Sun, 10 Feb 2008 12:48:53 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW000603APGCV00@nwk-avmta-1.sfbay.Sun.COM>; Sat, 09 Feb 2008 20:48:52 -0800 (PST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW000IGAAPF6120@nwk-avmta-1.sfbay.Sun.COM>; Sat, 09 Feb 2008 20:48:52 -0800 (PST) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1A4mqXS029216; Sun, 10 Feb 2008 04:48:52 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JW000H01ALASO00@mail-apac.sun.com> (original mail from Simon.Zheng@Sun.COM); Sun, 10 Feb 2008 12:48:50 +0800 (SGT) Received: from [192.168.0.194] ([123.112.48.247]) by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JW0007GLAPCBI72@mail-apac.sun.com>; Sun, 10 Feb 2008 12:48:50 +0800 (SGT) Date: Sun, 10 Feb 2008 12:48:50 +0800 From: "simon.zheng@sun.com" Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080207185748.GI22027@zruty.sfbay.sun.com> Sender: Simon.Zheng@sun.com To: Danek Duvall Cc: Brian Cameron , Shi-Ying Irene Huang , lsarc-ext@sun.com, jds-dev@sun.com Message-id: <1202618930.10083.61.camel@unknown> MIME-version: 1.0 X-Mailer: Evolution 2.12.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> Status: RO Content-Length: 3408 Danek, On Thu, 2008-02-07 at 10:57 -0800, Danek Duvall wrote: > On Thu, Feb 07, 2008 at 08:40:06PM +0800, simon.zheng wrote: > > > This library is used to build the "generate_extra_defs" utility executable, > > which is a tool to generate the signals and properties .defs files. > > > > [ ... ] > > > > Eventally, .defs files and gmmproc work together to generate real .cc and > > .h source files. More info is > > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html > > This is incredibly confusing. That page doesn't really explain much except > how to copy another project that's already done all the work. > > From what I read in the gtkmm docs, it looks like the gmmproc executable is > used to convert .hg and .ccg files into .h and .cc files, which are then > compiled. That would indicate that gmmproc should be in /usr/bin, and be > at a high stability level. But I see no documentation on generate_extra_defs, > or on libglibmm_generate_extra_defs-2.4, so I still don't have a handle on > what they're for. Thanks for your reading docs. Because I'm on vocation, I probably response slowly. After double-check, my previous descriptions isn't precise. Please ignore them. To generate .h and .cc files from .hg and ccg, gmmproc is executed like this. $./gmmproc -I ../../tools/m4 --defs ./src Here, -I and --defs specifies m4 files and .defs files directory. That it, gmmproc needs to cooperate with two kinds of files, .m4 and .defs. In fact, gtkmm svn repository has included these files beforehand. Therefore, no extra work for them needs to be done when building. The complete steps is below: - STEP 0: Write .m4, .ccg, .hg files and prepare .defs files, put them into svn repository. This is done before real building. - STEP 1: Preprocess of building. Use gmmproc to get .c and .h source files. - STEP 2: Compiling of building. Create gtkmm library from source files. > > Is generate_extra_defs something you'd put in a makefile to run over the > .hg and .ccg files to generate a .defs file? No, generate_extra_defs isn't put into any makefile. Usually generate_extra_defs is run manually by the developer to generate new .defs file, and then put these pre-generated .defs file into source repository. For example, when gtk+ C library is upgraded and a new widget class is added, gtk_signals.defs needs to be updated accordingly. Firstly, the developer modifies generate_defs_gtk.cc, then build generate_extra_defs binary. After that, he run generate_extra_defs manually to generate the new gtk_signals.defs. Finally he put the gtk_signals.def into svn repository. In one word, generate_extra_defs is just used to generate .defs before real building. So we don't develiver libglibmm_generate_extra_defs-2.4 library. It's private. > Is libglibmm_generate_extra_defs-2.4 something that's only ever linked to by > generate_extra_defs, or do user applications link to it as well? Yes, only generate_extra_defs linked to it. No other application needs this library. To summary, - Won't develiver /usr/lib/libglibmm_generate_extra_defs-2.4.so - Won't develiver /usr/include/glibmm-2.4/glibmm_generate_extra_defs - Keep gmmproc public. Since it's only used by building rather than by users directly, I hope move to /usr/lib/gmmproc, just like part of "/usr/libexec" on Solaris. Do you think it's reasonable? Thanks, -Simon > > Danek From danek.duvall@sun.com Tue Feb 12 09:10:39 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1CHAc9g009769 for ; Tue, 12 Feb 2008 09:10:38 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1CHAAR9006377; Tue, 12 Feb 2008 17:10:37 GMT Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW400M2FYDN0I00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Feb 2008 09:10:35 -0800 (PST) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW400J7VYDMVG20@nwk-avmta-1.sfbay.Sun.COM>; Tue, 12 Feb 2008 09:10:35 -0800 (PST) Received: from zruty.sfbay.sun.com (zruty.SFBay.Sun.COM [129.146.168.40]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1CHAWHN012001; Tue, 12 Feb 2008 09:10:33 -0800 (PST) Received: from zruty.sfbay.sun.com (localhost [127.0.0.1]) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2) with ESMTP id m1CHAWFU021161; Tue, 12 Feb 2008 09:10:32 -0800 (PST) Received: (from dduvall@localhost) by zruty.sfbay.sun.com (8.14.2+Sun/8.14.2/Submit) id m1CHAWOQ021160; Tue, 12 Feb 2008 09:10:32 -0800 (PST) Date: Tue, 12 Feb 2008 09:10:31 -0800 From: Danek Duvall Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <1202618930.10083.61.camel@unknown> To: "simon.zheng@sun.com" Cc: Brian Cameron , Shi-Ying Irene Huang , lsarc-ext@sun.com, jds-dev@sun.com Message-id: <20080212171031.GZ22027@zruty.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> User-Agent: Mutt/1.5.16 (2007-06-27) Status: RO Content-Length: 2775 On Sun, Feb 10, 2008 at 12:48:50PM +0800, simon.zheng@sun.com wrote: > To generate .h and .cc files from .hg and ccg, gmmproc is executed like > this. > > $./gmmproc -I ../../tools/m4 --defs ./src > > Here, -I and --defs specifies m4 files and .defs files directory. That > it, gmmproc needs to cooperate with two kinds of files, .m4 and .defs. > In fact, gtkmm svn repository has included these files beforehand. > Therefore, no extra work for them needs to be done when building. > > The complete steps is below: > - STEP 0: Write .m4, .ccg, .hg files and prepare .defs files, put them > into svn repository. This is done before real building. > - STEP 1: Preprocess of building. Use gmmproc to get .c and .h source > files. > - STEP 2: Compiling of building. Create gtkmm library from source files. Is this for any project based on gtkmm, or is this just when building gtkmm? The way you write the gmmproc commandline and then this step 2 sounds like the latter. I mostly don't care how you build this project; I care about how developers basing their own projects on this one will use the interfaces you provide. > > Is generate_extra_defs something you'd put in a makefile to run over > > the .hg and .ccg files to generate a .defs file? > > No, generate_extra_defs isn't put into any makefile. Usually > generate_extra_defs is run manually by the developer to generate new > .defs file, and then put these pre-generated .defs file into source > repository. Sort of like checking .o files into the repository? Why don't developers simply keep the source checked in, and all derived files built via the build system? > For example, when gtk+ C library is upgraded and a new widget class is > added, gtk_signals.defs needs to be updated accordingly. Firstly, the > developer modifies generate_defs_gtk.cc, then build generate_extra_defs > binary. After that, he run generate_extra_defs manually to generate the > new gtk_signals.defs. Finally he put the gtk_signals.def into svn > repository. > > In one word, generate_extra_defs is just used to generate .defs before > real building. So we don't develiver libglibmm_generate_extra_defs-2.4 > library. It's private. I think I'm understanding the architecture here less and less. Are you talking about building gtkmm, or some random other project that uses gtkmm? > - Keep gmmproc public. Since it's only used by building rather than by > users directly, I hope move to /usr/lib/gmmproc, just like part of > "/usr/libexec" on Solaris. Do you think it's reasonable? /usr/bin hold plenty of executables that are only useful to developers, so that's where I'd expect it to be. Do typical linux systems put it in /usr/libexec? If so, do makefiles and configure scripts tend to try to find it there? Danek From Ghee.Teo@sun.com Tue Feb 12 10:23:59 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1CINwwT015579 for ; Tue, 12 Feb 2008 10:23:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m1CINeDU014693; Wed, 13 Feb 2008 02:23:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW50020D1RW7G00@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Feb 2008 10:23:56 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW5001PS1RSJS10@nwk-avmta-2.sfbay.sun.com>; Tue, 12 Feb 2008 10:23:53 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1CINqfh002239; Tue, 12 Feb 2008 18:23:52 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW5004011OL2100@fe-emea-09.sun.com> (original mail from Ghee.Teo@Sun.COM) ; Tue, 12 Feb 2008 18:23:51 +0000 (GMT) Received: from [129.156.226.43] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW500AJR1RR60F0@fe-emea-09.sun.com>; Tue, 12 Feb 2008 18:23:51 +0000 (GMT) Date: Tue, 12 Feb 2008 18:26:26 +0000 From: Ghee Teo Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <20080212171031.GZ22027@zruty.sfbay.sun.com> Sender: Ghee.Teo@sun.com To: Danek Duvall Cc: "simon.zheng@sun.com" , Brian Cameron , Shi-Ying Irene Huang , lsarc-ext@sun.com, jds-dev@sun.com Message-id: <47B1E4D2.1090403@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> <20080212171031.GZ22027@zruty.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.6 (X11/20071119) Status: RO Content-Length: 3693 Hi Danek, I have a brief discussion with Simon after his last reply. I think I managed to 'convince' him that gmmproc is really a project private [1] interface. That is it is provided by glibmm to allow itself and other gtkmm modules to generate C++ code from specification language such as defs and so on. Its use outside gtkmm itself not not very generic as C++ developers are likely to write their apps from scratch or other tools and unlikely to use gmmproc. I am in the process of updating the interface table and also consolidate the various discussion points. Would like to do a quick review before I send out to this list again. Mostly by this time tomorrow :) Thanks -Ghee [1] Whatever the equivalent of the new taxonomy :) need to check. Danek Duvall wrote: > On Sun, Feb 10, 2008 at 12:48:50PM +0800, simon.zheng@sun.com wrote: > > >> To generate .h and .cc files from .hg and ccg, gmmproc is executed like >> this. >> >> $./gmmproc -I ../../tools/m4 --defs ./src >> >> Here, -I and --defs specifies m4 files and .defs files directory. That >> it, gmmproc needs to cooperate with two kinds of files, .m4 and .defs. >> In fact, gtkmm svn repository has included these files beforehand. >> Therefore, no extra work for them needs to be done when building. >> >> The complete steps is below: >> - STEP 0: Write .m4, .ccg, .hg files and prepare .defs files, put them >> into svn repository. This is done before real building. >> - STEP 1: Preprocess of building. Use gmmproc to get .c and .h source >> files. >> - STEP 2: Compiling of building. Create gtkmm library from source files. >> > > Is this for any project based on gtkmm, or is this just when building > gtkmm? The way you write the gmmproc commandline and then this step 2 > sounds like the latter. I mostly don't care how you build this project; I > care about how developers basing their own projects on this one will use > the interfaces you provide. > > >>> Is generate_extra_defs something you'd put in a makefile to run over >>> the .hg and .ccg files to generate a .defs file? >>> >> No, generate_extra_defs isn't put into any makefile. Usually >> generate_extra_defs is run manually by the developer to generate new >> .defs file, and then put these pre-generated .defs file into source >> repository. >> > > Sort of like checking .o files into the repository? Why don't developers > simply keep the source checked in, and all derived files built via the > build system? > > >> For example, when gtk+ C library is upgraded and a new widget class is >> added, gtk_signals.defs needs to be updated accordingly. Firstly, the >> developer modifies generate_defs_gtk.cc, then build generate_extra_defs >> binary. After that, he run generate_extra_defs manually to generate the >> new gtk_signals.defs. Finally he put the gtk_signals.def into svn >> repository. >> >> In one word, generate_extra_defs is just used to generate .defs before >> real building. So we don't develiver libglibmm_generate_extra_defs-2.4 >> library. It's private. >> > > I think I'm understanding the architecture here less and less. Are you > talking about building gtkmm, or some random other project that uses gtkmm? > > >> - Keep gmmproc public. Since it's only used by building rather than by >> users directly, I hope move to /usr/lib/gmmproc, just like part of >> "/usr/libexec" on Solaris. Do you think it's reasonable? >> > > /usr/bin hold plenty of executables that are only useful to developers, so > that's where I'd expect it to be. Do typical linux systems put it in > /usr/libexec? If so, do makefiles and configure scripts tend to try to > find it there? > > Danek > From Ghee.Teo@sun.com Wed Feb 13 03:54:17 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1DBsHaq023563 for ; Wed, 13 Feb 2008 03:54:17 -0800 (PST) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1DBsGcA026507; Wed, 13 Feb 2008 03:54:16 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JW600J05EEDFW00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 03:54:13 -0800 (PST) Received: from gmp-eb-mail-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JW600EPQEEA0L30@nwk-avmta-1.sfbay.Sun.COM>; Wed, 13 Feb 2008 03:54:11 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m1DBsADa009048; Wed, 13 Feb 2008 11:54:10 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JW600801DZX1800@fe-emea-09.sun.com> (original mail from Ghee.Teo@Sun.COM) ; Wed, 13 Feb 2008 11:54:10 +0000 (GMT) Received: from [129.156.220.40] by fe-emea-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JW600KGIEE82X80@fe-emea-09.sun.com>; Wed, 13 Feb 2008 11:54:09 +0000 (GMT) Date: Wed, 13 Feb 2008 11:54:08 +0000 From: Ghee Teo Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47B1E4D2.1090403@sun.com> Sender: Ghee.Teo@sun.com To: lsarc-ext@sun.com Cc: Ghee Teo , Danek Duvall , "simon.zheng@sun.com" , Brian Cameron , Shi-Ying Irene Huang , jds-dev@sun.com Reply-to: Ghee.Teo@sun.com Message-id: <47B2DA60.4080408@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_5Xu7xjPZ647/2Skt7zeFAA)" X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> <20080212171031.GZ22027@zruty.sfbay.sun.com> <47B1E4D2.1090403@sun.com> User-Agent: Thunderbird 2.0.0.9 (X11/20080116) Status: RO Content-Length: 11308 This is a multi-part message in MIME format. --Boundary_(ID_5Xu7xjPZ647/2Skt7zeFAA) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi, Attached is the updated version of ARC Fast Track materials. The following issues raised and discussed which are now summarized as follow: (1) Not to deliver of g++ compiled libraries This is now considered out of scope for this ARC fast-track due to the many issues raised over the brief period. If there is a need in the future to provide g++ compiled libraries this will be addressed in a subsequent case. (2) Libraries and .pc files are classified as Uncommitted instead of Volatile see updated interface exported table. .pc is the recommended way to access include files and also libraries by applications in general for JDS. (3) Tools for generation of wrapper code are classified as Consolidation Private See updated interface table and rationale for so doing. I believe any other points raised are either have been resolved during the threads or included here above. Should I have missed any other point, feel free to raise. Thanks, -Ghee --Boundary_(ID_5Xu7xjPZ647/2Skt7zeFAA) Content-type: text/plain; name=gtkmm-LSARC-2008-074-revised-13Feb2008.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=gtkmm-LSARC-2008-074-revised-13Feb2008.txt Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, Simon Zheng 1.3. Date of This Document: 01/30/08 1.5. Email Aliases: 1.5.1. Responsible Manager: leo.binchy@sun.com 1.5.2. Responsible Engineer:ghee.teo@sun.com, chris.wang@sun.com, elaine.xiong@sun.com, simon.zheng@sun.com 2. Project Summary 2.1. Project Description: libsigc++ implements a typesafe callback system for use in widget libraries, abstract interfaces, and general programming. It allows users to define signals and to connect those signals to any callback function, either global or a member function, regardless of whether it is static or virtual. It contains adaptor classes for connecting dissimilar callbacks and has an ease of use unmatched by other C++ callback libraries. cairomm is a C++ wrapper for the cairo graphics library. It offers all the power cairo with an interface familiar to C++ developers, including use of the Standard Template Library where it makes sense. Even though cairomm can be used on its own, it is often used together with the higher level toolkit C++ wrapper, gtkmm. glibmm is a set of C++ bindings for Glib2 Library, including cross- platform APIs such as a std::string-like UTF8 string class, string utility methods, such as a text encoding converter API, file access, and threads. gtkmm is the official C++ interface for the popular GUI library GTK+. Highlights include typesafe callbacks, and a comprehensive set of widgets that are easily extensible via inheritance. You can create user interfaces either in code or with the Glade User Interface designer, using libglademm. There's extensive documentation, including API reference and a tutorial. 2.2. Risks and Assumptions: gtkmm and glibmm follow the official GNOME Platform Bindings release schedule. This guarantees API/ABI-stability and new releases on a predictable schedule, delivering C++ API for the underlying GTK+ and GNOME APIs as soon as possible. The problem we need deal with is that of the different C++ ABIs of Sun Studio CC and GNU g++. Now that Sun Studio is available as a free download it's not such a big problem, but there are modules that won't build with Sun Studio. However Sun Studio C++ has maintained a stable C++ ABI for over a decade. Considering the g++ compiler in Solaris can't build any 64-bit binaries that are actually usable, we only deliver these packages build with Sun Studio. For those modules that won't build with Sun Studio, It is maintainer's responsibility to fix the build problems. We propose to minimize the risk by first delivering a set of gtkmm, glibmm, cairomm and sigc++ libraries which are built using Sun Studio compilers and in subsequent case to address the provision of g++ compiled libraries that may address specific needs accordingly. 4. Technical Description: 4.1. Details: libsigc++ provides the following Features: - Compile time typesafe callbacks (faster than run time checks) - Typesafe violations report line number correctly with template names (no tracing template failures into headers) - No compiler extensions or meta compilers required - Proper handling of dynamic objects and signals (deleted objects will not cause segmentation faults) - Extendable API at any level: signal, slot, connection and trackable - Extensions do not require alteration of basic components - User definable accumulators - A variety of adaptors to change the callback signature: bind, hide, retype, compose and lambda call groups - Various compilers and platforms are supported: gcc, cygwin, mingw32, MS .NET 2003, Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, IRIX MipsPro. cairomm is part of the gtkmm (gtk--) framework to allow developers to make full use of the capabilities of Object Oriented Programming language features as in C++. Cairo is a graphics description and rendering library. Cairomm provides classes that allow the cairo API to be accessed in an Object Oriented constructs. Cairo allow graphics to be created programmatical in its own language and the be rendered onto surfaces of specific target file formats, such as PostScript,PDF and so on. Current supported rendering surfaces are: - Image Surface (memory buffers) - PDF Surface - PostScript Surface - SVG Surface - Xlib Surface (X11 based systems) - Win32 Surface (Windows) - Quartz Surface (MacOS) - Glitz (OpenGL-accelerated, experimental not fully supported) These surfaces can then be augmented with the upper layer of libraries like that of gtkmm to create GUI application. To simplify the creation of C++ binding for gtkmm, glibmm delivers tools called gmmproc and generate_wrap_init.pl that can create wrapper for other glib/GObject-based libraries. For example, gtkmm uses this to generate most of its source code. The details on how to do this is described in Reference [7]. gtkmm provides the following Features: - Use inheritance to derive custom widgets. - Type-safe signal handlers, in standard C++. - Polymorphism. - Use of Standard C++ Library, including strings, containers, and iterators. - Full internationalisation with UTF8. - Complete C++ memory management - Object composition - Automatic deallocation of dynamically allocated widgets. - Full use of C++ namespaces. - No macros. - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris (gcc, Forte), Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others Free software and free of cost for both Open Source and proprietary development. - Discussed, designed and implemented in public. 4.5. Interfaces: Exported Interfaces Interface Stability Comments --------------------- ---------------- --------------- SUNWsigcpp Uncommitted Package names SUNWsigcpp-devel Uncommitted SUNWcairomm Uncommitted SUNWcairomm-devel Uncommitted SUNWglibmm Uncommitted SUNWglibmm-devel Uncommitted SUNWgtkmm Uncommitted SUNWgtkmm-devel Uncommitted libsigc-2.0.so Volatile See Note 1. libcairomm-1.0.so Uncommitted libglibmm-2.4.so Uncommitted libatkmm-1.6.so Uncommitted libgtkmm-2.4.so Uncommitted libgdkmm-2.4.so Uncommitted libpangomm-1.4.so Uncommitted /usr/demo/jds/bin/gtkmm-demo Uncommitted glibmm-2.4/proc/gmmproc Consolidation See Note 2. Private glibmm-2.4/proc/generate_wrap_init.pl Consolidation See Note 2. Private /usr/lib/pkgconfig/atkmm-1.6.pc Uncommitted See Note 3. /usr/lib/pkgconfig/gtkmm-2.4.pc Uncommitted /usr/lib/pkgconfig/pangomm-1.4.pc Uncommitted /usr/lib/pkgconfig/cairomm-1.0.pc Uncommitted /usr/lib/pkgconfig/sigc++-2.0.pc Uncommitted /usr/lib/pkgconfig/glibmm-2.4.pc Uncommitted Note 1: We classified this as Volatile as we have little working history with this particular community, thus a lack of reasonable certainly how well will they keep the interface stable. NOTE 2: Programs which used required by the upper stack, namely, gtkmm module to generate the C++ files based on some declarative language. Since its potential usage outside the stack is minimum, hence the Private interface. Note 3: All the header file include path are included are accessible by the *.pc files, hence making these Uncomiitted. Imported Interfaces Interface Stability Comments --------------------- ---------------- ---------------------- GNOME Committed Platform Libraries Committed LSARC/2007/520 GNOME 2.20 GTK+ library 4.9. I18N/L10N Impact: The JDS team and the G11N are working together to evaluation and provide I18N/L10N support 4.10. Packaging & Delivery: The project will be delivering the following packages: SUNWgtkmm SUNWgtkmm-devel SUNWglibmm SUNWglibmm-devel SUNWcairomm SUNWcairomm-devel SUNWsigcpp SUNWsigcpp-devel 5. Reference Documents: [1] gtkmm glibmm homepage http://www.gtkmm.org/ [2] cairomm homepage - http://cairographics.org/cairomm [3] cairomm download: http://cairographics.org/releases/ [4] libsigc++ Homepage - http://libsigc.sourceforge.net [5] libsigc++ Tutorial: http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ [6] libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ [7] Wrapping C Libraries with gmmproc: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html --Boundary_(ID_5Xu7xjPZ647/2Skt7zeFAA)-- From Irene.Huang@sun.com Sun Feb 17 23:50:29 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1I7oTkB026820 for ; Sun, 17 Feb 2008 23:50:29 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m1I7oShl020729; Sun, 17 Feb 2008 23:50:28 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWF00L0HCG3XO00@brm-avmta-1.central.sun.com>; Mon, 18 Feb 2008 00:50:27 -0700 (MST) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWF00DSACG1D950@brm-avmta-1.central.sun.com>; Mon, 18 Feb 2008 00:50:26 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1I7oZOF012403; Mon, 18 Feb 2008 07:50:35 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JWF00701CDWUY00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Mon, 18 Feb 2008 15:50:25 +0800 (SGT) Received: from [129.158.217.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWF0061RCFZKDK2@mail-apac.sun.com>; Mon, 18 Feb 2008 15:50:24 +0800 (SGT) Date: Mon, 18 Feb 2008 15:48:26 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47B2DA60.4080408@sun.com> Sender: Irene.Huang@sun.com To: Ghee.Teo@sun.com Cc: lsarc-ext@sun.com, Danek Duvall , "simon.zheng@sun.com" , Brian Cameron , Shi-Ying Irene Huang , jds-dev@sun.com Message-id: <1203320906.1087.89.camel@goalie> MIME-version: 1.0 X-Mailer: Evolution 2.12.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> <20080212171031.GZ22027@zruty.sfbay.sun.com> <47B1E4D2.1090403@sun.com> <47B2DA60.4080408@sun.com> Status: RO Content-Length: 11633 Hi, all I am setting the new time out for this case to be Feb 20th, 2008, in order to get it in to Indiana (hopefully). Thanks --Irene On Wed, 2008-02-13 at 11:54 +0000, Ghee Teo wrote: > Hi, > > Attached is the updated version of ARC Fast Track materials. > > The following issues raised and discussed which are now summarized as > follow: > > (1) Not to deliver of g++ compiled libraries > This is now considered out of scope for this ARC fast-track due to the many > issues raised over the brief period. If there is a need in the future to > provide > g++ compiled libraries this will be addressed in a subsequent case. > > (2) Libraries and .pc files are classified as Uncommitted instead of > Volatile > see updated interface exported table. > .pc is the recommended way to access include files and also libraries by > applications > in general for JDS. > > (3) Tools for generation of wrapper code are classified as Consolidation > Private > See updated interface table and rationale for so doing. > > I believe any other points raised are either have been resolved during > the threads > or included here above. Should I have missed any other point, feel free > to raise. > > Thanks, > > -Ghee > plain text document attachment > (gtkmm-LSARC-2008-074-revised-13Feb2008.txt) > Copyright 2008 Sun Microsystems > > 1. Introduction > 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm > > 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, > Simon Zheng > > 1.3. Date of This Document: 01/30/08 > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy@sun.com > 1.5.2. Responsible Engineer:ghee.teo@sun.com, > chris.wang@sun.com, > elaine.xiong@sun.com, > simon.zheng@sun.com > > 2. Project Summary > 2.1. Project Description: > libsigc++ implements a typesafe callback system for use in widget > libraries, abstract interfaces, and general programming. It allows users > to define signals and to connect those signals to any callback function, > either global or a member function, regardless of whether it is static or > virtual. It contains adaptor classes for connecting dissimilar callbacks > and has an ease of use unmatched by other C++ callback libraries. > > cairomm is a C++ wrapper for the cairo graphics library. It offers all > the power cairo with an interface familiar to C++ developers, including > use of the Standard Template Library where it makes sense. Even though > cairomm can be used on its own, it is often used together with the > higher level toolkit C++ wrapper, gtkmm. > > glibmm is a set of C++ bindings for Glib2 Library, including cross- > platform APIs such as a std::string-like UTF8 string class, string > utility methods, such as a text encoding converter API, file access, and > threads. > > gtkmm is the official C++ interface for the popular GUI library GTK+. > Highlights include typesafe callbacks, and a comprehensive set of > widgets that are easily extensible via inheritance. You can create user > interfaces either in code or with the Glade User Interface designer, > using libglademm. There's extensive documentation, including API > reference and a tutorial. > > > > 2.2. Risks and Assumptions: > gtkmm and glibmm follow the official GNOME Platform Bindings release > schedule. This guarantees API/ABI-stability and new releases on a > predictable schedule, delivering C++ API for the underlying GTK+ and > GNOME APIs as soon as possible. > > The problem we need deal with is that of the different C++ ABIs of Sun > Studio CC and GNU g++. Now that Sun Studio is available as a free > download it's not such a big problem, but there are modules that won't > build with Sun Studio. However Sun Studio C++ has maintained a stable > C++ ABI for over a decade. Considering the g++ compiler in Solaris can't > build any 64-bit binaries that are actually usable, we only deliver > these packages build with Sun Studio. For those modules that won't build > with Sun Studio, It is maintainer's responsibility to fix the build > problems. > > We propose to minimize the risk by first delivering a set of gtkmm, > glibmm, cairomm and sigc++ libraries which are built using Sun Studio > compilers and in subsequent case to address the provision of g++ > compiled libraries that may address specific needs accordingly. > > 4. Technical Description: > 4.1. Details: > libsigc++ provides the following Features: > > - Compile time typesafe callbacks (faster than run time checks) > - Typesafe violations report line number correctly with template > names (no tracing template failures into headers) > - No compiler extensions or meta compilers required > - Proper handling of dynamic objects and signals (deleted objects will > not cause segmentation faults) > - Extendable API at any level: signal, slot, connection and trackable > - Extensions do not require alteration of basic components > - User definable accumulators > - A variety of adaptors to change the callback signature: bind, hide, > retype, compose and lambda call groups > - Various compilers and platforms are supported: gcc, cygwin, mingw32, > MS .NET 2003, Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, > IRIX MipsPro. > > cairomm is part of the gtkmm (gtk--) framework to allow developers to > make full use of the capabilities of Object Oriented Programming > language features as in C++. > > Cairo is a graphics description and rendering library. Cairomm provides > classes that allow the cairo API to be accessed in an Object Oriented > constructs. Cairo allow graphics to be created programmatical in its own > language and the be rendered onto surfaces of specific target file > formats, such as PostScript,PDF and so on. > Current supported rendering surfaces are: > - Image Surface (memory buffers) > - PDF Surface > - PostScript Surface > - SVG Surface > - Xlib Surface (X11 based systems) > - Win32 Surface (Windows) > - Quartz Surface (MacOS) > - Glitz (OpenGL-accelerated, experimental not fully supported) > > These surfaces can then be augmented with the upper layer of libraries > like that of gtkmm to create GUI application. > > To simplify the creation of C++ binding for gtkmm, glibmm delivers tools > called gmmproc and generate_wrap_init.pl that can create wrapper for > other glib/GObject-based libraries. For example, gtkmm uses this to > generate most of its source code. The details on how to do this is > described in Reference [7]. > > > gtkmm provides the following Features: > - Use inheritance to derive custom widgets. > - Type-safe signal handlers, in standard C++. > - Polymorphism. > - Use of Standard C++ Library, including strings, containers, and > iterators. > - Full internationalisation with UTF8. > - Complete C++ memory management > - Object composition > - Automatic deallocation of dynamically allocated widgets. > - Full use of C++ namespaces. > - No macros. > - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris > (gcc, Forte), Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others > Free software and free of cost for both Open Source and proprietary > development. > - Discussed, designed and implemented in public. > > > 4.5. Interfaces: > > Exported Interfaces > Interface Stability Comments > --------------------- ---------------- --------------- > SUNWsigcpp Uncommitted Package names > SUNWsigcpp-devel Uncommitted > SUNWcairomm Uncommitted > SUNWcairomm-devel Uncommitted > SUNWglibmm Uncommitted > SUNWglibmm-devel Uncommitted > SUNWgtkmm Uncommitted > SUNWgtkmm-devel Uncommitted > > libsigc-2.0.so Volatile See Note 1. > libcairomm-1.0.so Uncommitted > libglibmm-2.4.so Uncommitted > libatkmm-1.6.so Uncommitted > libgtkmm-2.4.so Uncommitted > libgdkmm-2.4.so Uncommitted > libpangomm-1.4.so Uncommitted > /usr/demo/jds/bin/gtkmm-demo Uncommitted > glibmm-2.4/proc/gmmproc Consolidation See Note 2. > Private > glibmm-2.4/proc/generate_wrap_init.pl Consolidation See Note 2. > Private > > /usr/lib/pkgconfig/atkmm-1.6.pc Uncommitted See Note 3. > /usr/lib/pkgconfig/gtkmm-2.4.pc Uncommitted > /usr/lib/pkgconfig/pangomm-1.4.pc Uncommitted > /usr/lib/pkgconfig/cairomm-1.0.pc Uncommitted > /usr/lib/pkgconfig/sigc++-2.0.pc Uncommitted > /usr/lib/pkgconfig/glibmm-2.4.pc Uncommitted > > Note 1: We classified this as Volatile as we have little working history > with this particular community, thus a lack of reasonable > certainly how well will they keep the interface stable. > > NOTE 2: Programs which used required by the upper stack, namely, gtkmm > module to generate the C++ files based on some declarative > language. Since its potential usage outside the stack is > minimum, hence the Private interface. > > Note 3: All the header file include path are included are accessible by > the *.pc files, hence making these Uncomiitted. > > > Imported Interfaces > Interface Stability Comments > --------------------- ---------------- ---------------------- > > GNOME Committed Platform Libraries Committed LSARC/2007/520 > GNOME 2.20 > GTK+ library > > > > 4.9. I18N/L10N Impact: > The JDS team and the G11N are working together to evaluation and > provide I18N/L10N support > > 4.10. Packaging & Delivery: > The project will be delivering the following packages: > SUNWgtkmm > SUNWgtkmm-devel > SUNWglibmm > SUNWglibmm-devel > SUNWcairomm > SUNWcairomm-devel > SUNWsigcpp > SUNWsigcpp-devel > > > 5. Reference Documents: > [1] gtkmm glibmm homepage http://www.gtkmm.org/ > [2] cairomm homepage - http://cairographics.org/cairomm > [3] cairomm download: http://cairographics.org/releases/ > [4] libsigc++ Homepage - http://libsigc.sourceforge.net > [5] libsigc++ Tutorial: > http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ > [6] libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ > [7] Wrapping C Libraries with gmmproc: > http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html > From Irene.Huang@sun.com Wed Feb 20 18:59:23 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m1L2xNSg023918 for ; Wed, 20 Feb 2008 18:59:23 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m1L2xHQc008260; Thu, 21 Feb 2008 02:59:21 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JWK0000BIYV0S00@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 19:59:20 -0700 (MST) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JWK00IYXIYU4U30@brm-avmta-1.central.sun.com>; Wed, 20 Feb 2008 19:59:19 -0700 (MST) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m1L2xLKa010362; Thu, 21 Feb 2008 02:59:21 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JWK00D01IW7AH00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Thu, 21 Feb 2008 10:59:18 +0800 (SGT) Received: from [129.158.219.209] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JWK0060KIYSKKAJ@mail-apac.sun.com>; Thu, 21 Feb 2008 10:59:18 +0800 (SGT) Date: Thu, 21 Feb 2008 10:59:47 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <1203320906.1087.89.camel@goalie> Sender: Irene.Huang@sun.com To: Irene Huang Cc: Ghee.Teo@sun.com, lsarc-ext@sun.com, Danek Duvall , "simon.zheng@sun.com" , Brian Cameron , Shi-Ying Irene Huang , jds-dev@sun.com Message-id: <47BCE923.1030803@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> <20080212171031.GZ22027@zruty.sfbay.sun.com> <47B1E4D2.1090403@sun.com> <47B2DA60.4080408@sun.com> <1203320906.1087.89.camel@goalie> User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) Status: RO Content-Length: 11997 Closing as approved, since no further discussion after the update of the spec. --Irene Irene Huang wrote: > Hi, all > > I am setting the new time out for this case to be Feb 20th, 2008, in > order to get it in to Indiana (hopefully). > > Thanks > > --Irene > On Wed, 2008-02-13 at 11:54 +0000, Ghee Teo wrote: > >> Hi, >> >> Attached is the updated version of ARC Fast Track materials. >> >> The following issues raised and discussed which are now summarized as >> follow: >> >> (1) Not to deliver of g++ compiled libraries >> This is now considered out of scope for this ARC fast-track due to the many >> issues raised over the brief period. If there is a need in the future to >> provide >> g++ compiled libraries this will be addressed in a subsequent case. >> >> (2) Libraries and .pc files are classified as Uncommitted instead of >> Volatile >> see updated interface exported table. >> .pc is the recommended way to access include files and also libraries by >> applications >> in general for JDS. >> >> (3) Tools for generation of wrapper code are classified as Consolidation >> Private >> See updated interface table and rationale for so doing. >> >> I believe any other points raised are either have been resolved during >> the threads >> or included here above. Should I have missed any other point, feel free >> to raise. >> >> Thanks, >> >> -Ghee >> plain text document attachment >> (gtkmm-LSARC-2008-074-revised-13Feb2008.txt) >> Copyright 2008 Sun Microsystems >> >> 1. Introduction >> 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, and gtkmm >> >> 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, Elaine Xiong, >> Simon Zheng >> >> 1.3. Date of This Document: 01/30/08 >> >> 1.5. Email Aliases: >> 1.5.1. Responsible Manager: leo.binchy@sun.com >> 1.5.2. Responsible Engineer:ghee.teo@sun.com, >> chris.wang@sun.com, >> elaine.xiong@sun.com, >> simon.zheng@sun.com >> >> 2. Project Summary >> 2.1. Project Description: >> libsigc++ implements a typesafe callback system for use in widget >> libraries, abstract interfaces, and general programming. It allows users >> to define signals and to connect those signals to any callback function, >> either global or a member function, regardless of whether it is static or >> virtual. It contains adaptor classes for connecting dissimilar callbacks >> and has an ease of use unmatched by other C++ callback libraries. >> >> cairomm is a C++ wrapper for the cairo graphics library. It offers all >> the power cairo with an interface familiar to C++ developers, including >> use of the Standard Template Library where it makes sense. Even though >> cairomm can be used on its own, it is often used together with the >> higher level toolkit C++ wrapper, gtkmm. >> >> glibmm is a set of C++ bindings for Glib2 Library, including cross- >> platform APIs such as a std::string-like UTF8 string class, string >> utility methods, such as a text encoding converter API, file access, and >> threads. >> >> gtkmm is the official C++ interface for the popular GUI library GTK+. >> Highlights include typesafe callbacks, and a comprehensive set of >> widgets that are easily extensible via inheritance. You can create user >> interfaces either in code or with the Glade User Interface designer, >> using libglademm. There's extensive documentation, including API >> reference and a tutorial. >> >> >> >> 2.2. Risks and Assumptions: >> gtkmm and glibmm follow the official GNOME Platform Bindings release >> schedule. This guarantees API/ABI-stability and new releases on a >> predictable schedule, delivering C++ API for the underlying GTK+ and >> GNOME APIs as soon as possible. >> >> The problem we need deal with is that of the different C++ ABIs of Sun >> Studio CC and GNU g++. Now that Sun Studio is available as a free >> download it's not such a big problem, but there are modules that won't >> build with Sun Studio. However Sun Studio C++ has maintained a stable >> C++ ABI for over a decade. Considering the g++ compiler in Solaris can't >> build any 64-bit binaries that are actually usable, we only deliver >> these packages build with Sun Studio. For those modules that won't build >> with Sun Studio, It is maintainer's responsibility to fix the build >> problems. >> >> We propose to minimize the risk by first delivering a set of gtkmm, >> glibmm, cairomm and sigc++ libraries which are built using Sun Studio >> compilers and in subsequent case to address the provision of g++ >> compiled libraries that may address specific needs accordingly. >> >> 4. Technical Description: >> 4.1. Details: >> libsigc++ provides the following Features: >> >> - Compile time typesafe callbacks (faster than run time checks) >> - Typesafe violations report line number correctly with template >> names (no tracing template failures into headers) >> - No compiler extensions or meta compilers required >> - Proper handling of dynamic objects and signals (deleted objects will >> not cause segmentation faults) >> - Extendable API at any level: signal, slot, connection and trackable >> - Extensions do not require alteration of basic components >> - User definable accumulators >> - A variety of adaptors to change the callback signature: bind, hide, >> retype, compose and lambda call groups >> - Various compilers and platforms are supported: gcc, cygwin, mingw32, >> MS .NET 2003, Sun Forte C++, Compaq C++, Intel C++, IBM AIX, Tru64, >> IRIX MipsPro. >> >> cairomm is part of the gtkmm (gtk--) framework to allow developers to >> make full use of the capabilities of Object Oriented Programming >> language features as in C++. >> >> Cairo is a graphics description and rendering library. Cairomm provides >> classes that allow the cairo API to be accessed in an Object Oriented >> constructs. Cairo allow graphics to be created programmatical in its own >> language and the be rendered onto surfaces of specific target file >> formats, such as PostScript,PDF and so on. >> Current supported rendering surfaces are: >> - Image Surface (memory buffers) >> - PDF Surface >> - PostScript Surface >> - SVG Surface >> - Xlib Surface (X11 based systems) >> - Win32 Surface (Windows) >> - Quartz Surface (MacOS) >> - Glitz (OpenGL-accelerated, experimental not fully supported) >> >> These surfaces can then be augmented with the upper layer of libraries >> like that of gtkmm to create GUI application. >> >> To simplify the creation of C++ binding for gtkmm, glibmm delivers tools >> called gmmproc and generate_wrap_init.pl that can create wrapper for >> other glib/GObject-based libraries. For example, gtkmm uses this to >> generate most of its source code. The details on how to do this is >> described in Reference [7]. >> >> >> gtkmm provides the following Features: >> - Use inheritance to derive custom widgets. >> - Type-safe signal handlers, in standard C++. >> - Polymorphism. >> - Use of Standard C++ Library, including strings, containers, and >> iterators. >> - Full internationalisation with UTF8. >> - Complete C++ memory management >> - Object composition >> - Automatic deallocation of dynamically allocated widgets. >> - Full use of C++ namespaces. >> - No macros. >> - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD (gcc), Solaris >> (gcc, Forte), Win32 (gcc, MSVC++ .Net 2003), MacOS X (gcc), others >> Free software and free of cost for both Open Source and proprietary >> development. >> - Discussed, designed and implemented in public. >> >> >> 4.5. Interfaces: >> >> Exported Interfaces >> Interface Stability Comments >> --------------------- ---------------- --------------- >> SUNWsigcpp Uncommitted Package names >> SUNWsigcpp-devel Uncommitted >> SUNWcairomm Uncommitted >> SUNWcairomm-devel Uncommitted >> SUNWglibmm Uncommitted >> SUNWglibmm-devel Uncommitted >> SUNWgtkmm Uncommitted >> SUNWgtkmm-devel Uncommitted >> >> libsigc-2.0.so Volatile See Note 1. >> libcairomm-1.0.so Uncommitted >> libglibmm-2.4.so Uncommitted >> libatkmm-1.6.so Uncommitted >> libgtkmm-2.4.so Uncommitted >> libgdkmm-2.4.so Uncommitted >> libpangomm-1.4.so Uncommitted >> /usr/demo/jds/bin/gtkmm-demo Uncommitted >> glibmm-2.4/proc/gmmproc Consolidation See Note 2. >> Private >> glibmm-2.4/proc/generate_wrap_init.pl Consolidation See Note 2. >> Private >> >> /usr/lib/pkgconfig/atkmm-1.6.pc Uncommitted See Note 3. >> /usr/lib/pkgconfig/gtkmm-2.4.pc Uncommitted >> /usr/lib/pkgconfig/pangomm-1.4.pc Uncommitted >> /usr/lib/pkgconfig/cairomm-1.0.pc Uncommitted >> /usr/lib/pkgconfig/sigc++-2.0.pc Uncommitted >> /usr/lib/pkgconfig/glibmm-2.4.pc Uncommitted >> >> Note 1: We classified this as Volatile as we have little working history >> with this particular community, thus a lack of reasonable >> certainly how well will they keep the interface stable. >> >> NOTE 2: Programs which used required by the upper stack, namely, gtkmm >> module to generate the C++ files based on some declarative >> language. Since its potential usage outside the stack is >> minimum, hence the Private interface. >> >> Note 3: All the header file include path are included are accessible by >> the *.pc files, hence making these Uncomiitted. >> >> >> Imported Interfaces >> Interface Stability Comments >> --------------------- ---------------- ---------------------- >> >> GNOME Committed Platform Libraries Committed LSARC/2007/520 >> GNOME 2.20 >> GTK+ library >> >> >> >> 4.9. I18N/L10N Impact: >> The JDS team and the G11N are working together to evaluation and >> provide I18N/L10N support >> >> 4.10. Packaging & Delivery: >> The project will be delivering the following packages: >> SUNWgtkmm >> SUNWgtkmm-devel >> SUNWglibmm >> SUNWglibmm-devel >> SUNWcairomm >> SUNWcairomm-devel >> SUNWsigcpp >> SUNWsigcpp-devel >> >> >> 5. Reference Documents: >> [1] gtkmm glibmm homepage http://www.gtkmm.org/ >> [2] cairomm homepage - http://cairographics.org/cairomm >> [3] cairomm download: http://cairographics.org/releases/ >> [4] libsigc++ Homepage - http://libsigc.sourceforge.net >> [5] libsigc++ Tutorial: >> http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ >> [6] libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ >> [7] Wrapping C Libraries with gmmproc: >> http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html >> >> > > From Lloyd.Chambers@sun.com Tue Mar 11 09:56:18 2008 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BGuI0H028739 for ; Tue, 11 Mar 2008 09:56:18 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m2BGu3I9020962; Tue, 11 Mar 2008 09:56:18 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK0082PSDTUK00@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 10:56:17 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK005VKSDSW930@brm-avmta-1.central.sun.com>; Tue, 11 Mar 2008 10:56:16 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2BGuGMG025458; Tue, 11 Mar 2008 09:56:16 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXK00G01RE11500@fe-sfbay-09.sun.com> (original mail from Lloyd.Chambers@Sun.COM); Tue, 11 Mar 2008 09:56:16 -0700 (PDT) Received: from dhcp-usca14-133-110.SFBay.Sun.COM ([129.145.133.110]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JXK00ADDSDODW00@fe-sfbay-09.sun.com>; Tue, 11 Mar 2008 09:56:12 -0700 (PDT) Date: Tue, 11 Mar 2008 09:56:11 -0700 From: Lloyd L Chambers Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <47BCE923.1030803@sun.com> Sender: Lloyd.Chambers@sun.com To: Irene Huang Cc: Ghee.Teo@sun.com, lsarc-ext@sun.com, Danek Duvall , "simon.zheng@sun.com" , Brian Cameron , Shi-Ying Irene Huang , jds-dev@sun.com, Aarti Pai Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.919.2) Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200802010838.m118cXBF024576@sac.sfbay.sun.com> <20080205054750.GD28799@zruty.sfbay.sun.com> <47A8384C.4050908@sun.com> <47A88606.8080905@sun.com> <47AAFC26.8010801@sun.com> <20080207185748.GI22027@zruty.sfbay.sun.com> <1202618930.10083.61.camel@unknown> <20080212171031.GZ22027@zruty.sfbay.sun.com> <47B1E4D2.1090403@sun.com> <47B2DA60.4080408@sun.com> <1203320906.1087.89.camel@goalie> <47BCE923.1030803@sun.com> Status: RO Content-Length: 12534 Irene, As of March 11 the case is still "waiting fast-track". Please update the IAM file. Thanks, Lloyd On Feb 20, 2008, at 6:59 PM, Irene Huang wrote: > Closing as approved, since no further discussion after the update of > the spec. > > --Irene > Irene Huang wrote: >> Hi, all >> I am setting the new time out for this case to be Feb 20th, 2008, in >> order to get it in to Indiana (hopefully). >> >> Thanks >> --Irene On Wed, 2008-02-13 at 11:54 +0000, Ghee Teo wrote: >> >>> Hi, >>> >>> Attached is the updated version of ARC Fast Track materials. >>> >>> The following issues raised and discussed which are now summarized >>> as follow: >>> >>> (1) Not to deliver of g++ compiled libraries >>> This is now considered out of scope for this ARC fast-track due to >>> the many >>> issues raised over the brief period. If there is a need in the >>> future to provide >>> g++ compiled libraries this will be addressed in a subsequent case. >>> >>> (2) Libraries and .pc files are classified as Uncommitted instead >>> of Volatile >>> see updated interface exported table. >>> .pc is the recommended way to access include files and also >>> libraries by applications >>> in general for JDS. >>> >>> (3) Tools for generation of wrapper code are classified as >>> Consolidation Private >>> See updated interface table and rationale for so doing. >>> >>> I believe any other points raised are either have been resolved >>> during the threads >>> or included here above. Should I have missed any other point, feel >>> free to raise. >>> >>> Thanks, >>> >>> -Ghee >>> plain text document attachment >>> (gtkmm-LSARC-2008-074-revised-13Feb2008.txt) >>> Copyright 2008 Sun Microsystems >>> >>> 1. Introduction >>> 1.1. Project/Component Working Name: sigcpp, glibmm, cairomm, >>> and gtkmm >>> 1.2. Name of Document Author/Supplier: Ghee Teo, Chris Wang, >>> Elaine Xiong, Simon >>> Zheng >>> 1.3. Date of This Document: 01/30/08 >>> >>> 1.5. Email Aliases: >>> 1.5.1. Responsible Manager: leo.binchy@sun.com >>> 1.5.2. Responsible >>> Engineer:ghee.teo@sun.com, chris.wang@sun.com >>> , >>> elaine.xiong@sun.com, >>> simon.zheng@sun.com >>> 2. Project Summary >>> 2.1. Project Description: >>> libsigc++ implements a typesafe callback system for use in >>> widget libraries, abstract interfaces, and general >>> programming. It allows users to define signals and to connect >>> those signals to any callback function, either global or a member >>> function, regardless of whether it is static or >>> virtual. It contains adaptor classes for connecting dissimilar >>> callbacks >>> and has an ease of use unmatched by other C++ callback libraries. >>> >>> cairomm is a C++ wrapper for the cairo graphics library. It >>> offers all the power cairo with an interface familiar to C++ >>> developers, including use of the Standard Template Library where >>> it makes sense. Even though cairomm can be used on its own, it is >>> often used together with the higher level toolkit C++ wrapper, >>> gtkmm. >>> glibmm is a set of C++ bindings for Glib2 Library, >>> including cross- >>> platform APIs such as a std::string-like UTF8 string class, >>> string utility methods, such as a text encoding converter API, >>> file access, and threads. >>> >>> gtkmm is the official C++ interface for the popular GUI >>> library GTK+. Highlights include typesafe callbacks, and a >>> comprehensive set of widgets that are easily extensible via >>> inheritance. You can create user interfaces either in code or >>> with the Glade User Interface designer, using libglademm. There's >>> extensive documentation, including API reference and a tutorial. >>> >>> >>> 2.2. Risks and Assumptions: >>> gtkmm and glibmm follow the official GNOME Platform Bindings >>> release >>> schedule. This guarantees API/ABI-stability and new releases on a >>> predictable schedule, delivering C++ API for the underlying GTK+ >>> and GNOME APIs as soon as possible. The problem we >>> need deal with is that of the different C++ ABIs of Sun Studio CC >>> and GNU g++. Now that Sun Studio is available as a free download >>> it's not such a big problem, but there are modules that won't >>> build with Sun Studio. However Sun Studio C++ has maintained a >>> stable C++ ABI for over a decade. Considering the g++ compiler in >>> Solaris can't build any 64-bit binaries that are actually usable, >>> we only deliver these packages build with Sun Studio. For those >>> modules that won't build >>> with Sun Studio, It is maintainer's responsibility to fix the >>> build problems. >>> >>> We propose to minimize the risk by first delivering a set of gtkmm, >>> glibmm, cairomm and sigc++ libraries which are built using Sun >>> Studio >>> compilers and in subsequent case to address the provision of g++ >>> compiled libraries that may address specific needs accordingly. >>> 4. Technical Description: >>> 4.1. Details: >>> libsigc++ provides the following Features: >>> >>> - Compile time typesafe callbacks (faster than run time >>> checks) >>> - Typesafe violations report line number correctly with >>> template names (no tracing template failures into headers) >>> - No compiler extensions or meta compilers required >>> - Proper handling of dynamic objects and signals (deleted >>> objects will not cause segmentation faults) >>> - Extendable API at any level: signal, slot, connection >>> and trackable >>> - Extensions do not require alteration of basic components >>> - User definable accumulators >>> - A variety of adaptors to change the callback signature: >>> bind, hide, retype, compose and lambda call groups >>> - Various compilers and platforms are supported: gcc, >>> cygwin, mingw32, MS .NET 2003, Sun Forte C++, Compaq C++, >>> Intel C++, IBM AIX, Tru64, IRIX MipsPro. >>> >>> cairomm is part of the gtkmm (gtk--) framework to allow >>> developers to make full use of the capabilities of Object >>> Oriented Programming language features as in C++. >>> >>> Cairo is a graphics description and rendering library. Cairomm >>> provides classes that allow the cairo API to be accessed in an >>> Object Oriented constructs. Cairo allow graphics to be created >>> programmatical in its own language and the be rendered onto >>> surfaces of specific target file formats, such as PostScript,PDF >>> and so on. >>> Current supported rendering surfaces are: >>> - Image Surface (memory buffers) >>> - PDF Surface >>> - PostScript Surface >>> - SVG Surface >>> - Xlib Surface (X11 based systems) >>> - Win32 Surface (Windows) >>> - Quartz Surface (MacOS) >>> - Glitz (OpenGL-accelerated, experimental not fully supported) >>> >>> These surfaces can then be augmented with the upper layer of >>> libraries like that of gtkmm to create GUI application. >>> To simplify the creation of C++ binding for gtkmm, glibmm >>> delivers tools >>> called gmmproc and generate_wrap_init.pl that can create wrapper >>> for other glib/GObject-based libraries. For example, gtkmm uses >>> this to generate most of its source code. The details on how to >>> do this is described in Reference [7]. >>> >>> >>> gtkmm provides the following Features: >>> - Use inheritance to derive custom widgets. >>> - Type-safe signal handlers, in standard C++. >>> - Polymorphism. >>> - Use of Standard C++ Library, including strings, >>> containers, and iterators. >>> - Full internationalisation with UTF8. >>> - Complete C++ memory management >>> - Object composition >>> - Automatic deallocation of dynamically allocated widgets. >>> - Full use of C++ namespaces. >>> - No macros. >>> - Cross-platform: Linux (gcc), FreeBSD (gcc), NetBSD >>> (gcc), Solaris (gcc, Forte), Win32 (gcc, MSVC++ .Net 2003), >>> MacOS X (gcc), others Free software and free of cost for both >>> Open Source and proprietary development. >>> - Discussed, designed and implemented in public. >>> >>> 4.5. Interfaces: >>> >>> Exported Interfaces >>> Interface Stability >>> Comments --------------------- >>> ---------------- --------------- >>> SUNWsigcpp Uncommitted >>> Package names SUNWsigcpp-devel >>> Uncommitted >>> SUNWcairomm Uncommitted >>> SUNWcairomm-devel Uncommitted >>> SUNWglibmm >>> Uncommitted SUNWglibmm-devel >>> Uncommitted >>> SUNWgtkmm Uncommitted >>> SUNWgtkmm-devel Uncommitted >>> >>> libsigc-2.0.so Volatile See >>> Note 1. >>> libcairomm-1.0.so Uncommitted >>> libglibmm-2.4.so >>> Uncommitted >>> libatkmm-1.6.so Uncommitted >>> libgtkmm-2.4.so Uncommitted >>> libgdkmm-2.4.so Uncommitted >>> libpangomm-1.4.so Uncommitted >>> /usr/demo/jds/bin/gtkmm-demo Uncommitted >>> glibmm-2.4/proc/gmmproc Consolidation See >>> Note 2. >>> Private glibmm-2.4/proc/generate_wrap_init.pl >>> Consolidation See Note 2. >>> Private >>> >>> /usr/lib/pkgconfig/atkmm-1.6.pc Uncommitted See >>> Note 3. >>> /usr/lib/pkgconfig/gtkmm-2.4.pc Uncommitted >>> /usr/lib/pkgconfig/pangomm-1.4.pc Uncommitted >>> /usr/lib/pkgconfig/cairomm-1.0.pc Uncommitted >>> /usr/lib/pkgconfig/sigc++-2.0.pc Uncommitted >>> /usr/lib/pkgconfig/glibmm-2.4.pc Uncommitted >>> >>> Note 1: We classified this as Volatile as we have little working >>> history with this particular community, thus a lack of >>> reasonable certainly how well will they keep the interface stable. >>> NOTE 2: Programs which used required by the upper stack, namely, >>> gtkmm >>> module to generate the C++ files based on some declarative >>> language. Since its potential usage outside the stack is >>> minimum, hence the Private interface. >>> >>> Note 3: All the header file include path are included are >>> accessible by the *.pc files, hence making these Uncomiitted. >>> >>> >>> Imported Interfaces >>> Interface Stability >>> Comments --------------------- >>> ---------------- ---------------------- >>> GNOME Committed Platform Libraries >>> Committed LSARC/ >>> 2007 >>> / >>> 520 >>> GNOME >>> 2.20 GTK+ library >>> >>> >>> 4.9. I18N/L10N Impact: >>> The JDS team and the G11N are working together to evaluation and >>> provide I18N/L10N support >>> 4.10. Packaging & Delivery: >>> The project will be delivering the following packages: >>> SUNWgtkmm SUNWgtkmm-devel >>> SUNWglibmm >>> SUNWglibmm-devel >>> SUNWcairomm >>> SUNWcairomm-devel >>> SUNWsigcpp >>> SUNWsigcpp-devel >>> 5. Reference Documents: >>> [1] gtkmm glibmm homepage http://www.gtkmm.org/ >>> [2] cairomm homepage - http://cairographics.org/cairomm >>> [3] cairomm download: http://cairographics.org/releases/ >>> [4] libsigc++ Homepage - http://libsigc.sourceforge.net >>> [5] libsigc++ Tutorial: >>> http://libsigc.sourceforge.net/libsigc2/docs/manual/html/ >>> [6] libsigc++ API Reference - http://libsigc.sourceforge.net/libsigc2/docs/ >>> [7] Wrapping C Libraries with gmmproc: http://www.gtkmm.org/docs/gtkmm-2.4/docs/tutorial/html/chapter-wrapping-c-libraries.html >>> >>> >> >> > --- Lloyd L Chambers lloyd.chambers@sun.com Sun Microsystems, Inc From johnf@sr1-umpk-19.sfbay.sun.com Tue Mar 11 10:10:06 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BHA5E7001226 for ; Tue, 11 Mar 2008 10:10:05 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2BHA3Zj019828; Wed, 12 Mar 2008 01:10:03 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXK00AAET0PG500@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Mar 2008 10:10:01 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXK007NESZPOKA0@nwk-avmta-2.sfbay.sun.com>; Tue, 11 Mar 2008 10:09:26 -0700 (PDT) Received: from sr1-umpk-19.sfbay.sun.com (sr1-umpk-19.SFBay.Sun.COM [129.145.154.70]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m2BH9Mh9034686; Tue, 11 Mar 2008 10:09:22 -0700 (PDT) Received: from sr1-umpk-19.sfbay.sun.com (localhost [127.0.0.1]) by sr1-umpk-19.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2BH9Lux059377; Tue, 11 Mar 2008 10:09:21 -0700 (PDT) Received: (from johnf@localhost) by sr1-umpk-19.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m2BH9L8b059376; Tue, 11 Mar 2008 10:09:21 -0700 (PDT) Date: Tue, 11 Mar 2008 10:09:21 -0700 (PDT) From: John Fischer Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] To: Irene.Huang@sun.com, Lloyd.Chambers@sun.com Cc: Aarti.Pai@sun.com, Brian.Cameron@sun.com, Danek.Duvall@sun.com, Ghee.Teo@sun.com, Simon.Zheng@sun.com, jds-dev@sun.com, lsarc-ext@sun.com, sh162551@sac.sfbay.sun.com Message-id: <200803111709.m2BH9L8b059376@sr1-umpk-19.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 84 Irene, I have updated the IAM file for you to be 'closed approved'. Thanks, John From Irene.Huang@sun.com Wed Mar 12 01:55:01 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m2C8t0RO004403 for ; Wed, 12 Mar 2008 01:55:01 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m2C8sqUt010799; Wed, 12 Mar 2008 16:54:59 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0JXM001010RK9500@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Mar 2008 01:54:56 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0JXM00CMQ0RJBEA0@nwk-avmta-2.sfbay.sun.com>; Wed, 12 Mar 2008 01:54:56 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m2C8t16m011085; Wed, 12 Mar 2008 08:55:01 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JXM002010NNXR00@mail-apac.sun.com> (original mail from Irene.Huang@Sun.COM); Wed, 12 Mar 2008 16:54:54 +0800 (SGT) Received: from [129.158.217.138] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JXM00JHR0RGC708@mail-apac.sun.com>; Wed, 12 Mar 2008 16:54:54 +0800 (SGT) Date: Wed, 12 Mar 2008 16:55:14 +0800 From: Irene Huang Subject: Re: Gtkmm, Glibmm, Cairomm and libsigc++ for Indiana [LSARC/2008/074 FastTrack timeout 02/13/2008] In-reply-to: <200803111709.m2BH9L8b059376@sr1-umpk-19.sfbay.sun.com> Sender: Irene.Huang@sun.com To: John Fischer Cc: Lloyd.Chambers@sun.com, Aarti.Pai@sun.com, Brian.Cameron@sun.com, Danek.Duvall@sun.com, Ghee.Teo@sun.com, Simon.Zheng@sun.com, jds-dev@sun.com, lsarc-ext@sun.com, sh162551@sac.sfbay.sun.com Message-id: <1205312114.1606.16.camel@goalie> MIME-version: 1.0 X-Mailer: Evolution 2.12.1 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200803111709.m2BH9L8b059376@sr1-umpk-19.sfbay.sun.com> Status: RO Content-Length: 200 Thanks :( I thought I've updated it. --Irene On Tue, 2008-03-11 at 10:09 -0700, John Fischer wrote: > Irene, > > I have updated the IAM file for you to be 'closed approved'. > > Thanks, > > John