Re: GNUstep packaging by TWW tools
On 26 Dec 2006, at 20:02, T.J. Yang wrote: My plan 1. prepare gcc-4.1.1 for Solaris 10 intel (U2, 06/2006 version) first and down port lower version solaris and sparc cpu. This is fairly straightforward ... I've done it for 32 bit and 64bit solaris ... you shouldn't have any trouble. 2. package the gnustep core software(make,base,gui). I don't know CPAM at all ... but I've packaged these things using solaris native packaging (pkgmk etc) and a cursory scan of the pages at http://en.wikibooks.org/wiki/CPAM_with_TWW/User_Guide suggests that CPAM acts as a layer on top of pkgm, so it ought to be workable. 3. release package sources You will need to make a copyright assignment to the FSF to get the packaging source incorporated into the projects. See http://mediawiki.gnustep.org/index.php/ Developer_FAQ#How_do_I_assign_my_contribution.3F 4. Lobby gnustep development community to use TWW tool so TWW CPAM tool can help GNUstep's CPAD. This will be hard because asking people to switch to different tools using different processes. I don't know CPAM details, but if it produces a wrapper round a 'native' package format, such that the native package is still available, I expect there would be no resistance as it would allow us to build (and therefore provide easily on the ftp site) both the native packages and the higher-level CPAM packages. If on the other hand, it results in something which can only be installed with the CPAM installer, I expect it would be argued that we should just build packages in the 'native' formats, so that they can be installed without the need to download/use the CPAM tool. One issue though ... the list of supported operating systems for HPMS does not include ms-windows ... the whole point of this system is to wrap all other systems inside a single toolset, but if it omits what is arguably the second most important target operating system, then it's probably not actually very useful. I think it's therefore important to find out whether ms-windows support is available, or under development and near enough complete for you to join in and perfect it. If ms-windows support is available then this sounds like a very good idea. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep packaging by TWW tools
From: Richard Frith-Macdonald [EMAIL PROTECTED] To: T.J. Yang [EMAIL PROTECTED] CC: gnustep-dev@gnu.org Subject: Re: GNUstep packaging by TWW tools Date: Wed, 27 Dec 2006 10:59:51 + On 26 Dec 2006, at 20:02, T.J. Yang wrote: My plan 1. prepare gcc-4.1.1 for Solaris 10 intel (U2, 06/2006 version) first and down port lower version solaris and sparc cpu. This is fairly straightforward ... I've done it for 32 bit and 64bit solaris ... you shouldn't have any trouble. Great, would you mind to try out gcc-4.1.1 for GNUstep ? Currently I have 4.1.1 for Solaris 10 intel, it can compile helloword.m but it failed the configure script when compiling gnustep-base. looks like I need to relocate objc/objc.h to a path that can be found. 2. package the gnustep core software(make,base,gui). I don't know CPAM at all ... but I've packaged these things using solaris native packaging (pkgmk etc) and a cursory scan of the pages at http://en.wikibooks.org/wiki/CPAM_with_TWW/User_Guide suggests that CPAM acts as a layer on top of pkgm, so it ought to be workable. TWW's CPAM is an evolution not a revolution solution like OpenPKG. Existing knowledge of native packages still needed and depended upon. It make abstract software build process into a repeatable XML format. when building SVR4 package, TWW's pb tool will call up pkgmk to make the SVR4 package and if pb runs on RH Linux, then it will call up rpmbuild to build the package. 3. release package sources You will need to make a copyright assignment to the FSF to get the packaging source incorporated into the projects. See http://mediawiki.gnustep.org/index.php/ Developer_FAQ#How_do_I_assign_my_contribution.3F 4. Lobby gnustep development community to use TWW tool so TWW CPAM tool can help GNUstep's CPAD. This will be hard because asking people to switch to different tools using different processes. I don't know CPAM details, but if it produces a wrapper round a 'native' package format, such that the native package is still available, I expect there would be no resistance as it would allow us to build (and therefore provide easily on the ftp site) both the native packages and the higher-level CPAM packages. If on the other hand, it results in something which can only be installed with the CPAM installer, I expect it would be argued that we should just build packages in the 'native' formats, so that they can be installed without the need to download/use the CPAM tool. TWW package format is in pkg-inst format which is a zipped file/directory of native packages in native format. One can certainly unzip the TWW packages format into native ones and use pkgadd to do package installation. The downside is that the auto installation of depended software will then need to be installed manually. One issue though ... the list of supported operating systems for HPMS does not include ms-windows ... the whole point of this system is to wrap all other systems inside a single toolset, but if it omits what is arguably the second most important target operating system, then it's probably not actually very useful. I think it's therefore important to find out whether ms-windows support is available, or under development and near enough complete for you to join in and perfect it. If ms-windows support is available then this sounds like a very good idea. Correct, TWW tools for win32 is not ready yet but this doesn't prevent GNUstep (for Unix) to adopt the TWW tools. TWW tools(and all the software they packaged) are in GPL license so if an OS is not supported, we can port the tools over. I tried to port the tools to Linksys nslu2, Mac OS X and win32 with some progress but I reach my limit of ability and time.(Now you know I have these three OS at home ;). for TWW and win32, here is my finding and testing sb(software build) tool was ported over quite easily using cygwin. pb(package build) tool need more thinking because there so many PMS solutions for win32. Personally I favor WiX becuase it use xml file for describing package building and it is from vendor(MS). Using WiX will make pb wrapper much easier, it will be just TWW's XML converted to WiX's XML format. currently gnustep win32 is not using WiX for packaging, I hope this can be changed to use WiX. when TWW tools for win32 is ready, the conversion to use TWW will be easier. Regards tj _ Find sales, coupons, and free shipping, all in one place! MSN Shopping Sales Deals http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep packaging by TWW tools
No ... but there is little incentive for people to adopt it if it doesn't help packaging for our target systems. I agree GNUstep win32 has high priority because the vast amount of win32 machine in existence. TWW tools(and all the software they packaged) are in GPL license so if an OS is not supported, we can port the tools over. I tried to port the tools to Linksys nslu2, Mac OS X and win32 with some progress but I reach my limit of ability and time.(Now you know I have these three OS at home ;). for TWW and win32, here is my finding and testing sb(software build) tool was ported over quite easily using cygwin. But we don't use/support cygwin for GNUstep on windows ... so, while some people may have cygwin installed, most won't ... so we would need the build tool ported to run without having to install cygwin too. I remembered I tired mingw first but later back down to cygwin because cygwin was much easier to me. pb(package build) tool need more thinking because there so many PMS solutions for win32. Personally I favor WiX becuase it use xml file for describing package building and it is from vendor(MS). Using WiX will make pb wrapper much easier, it will be just TWW's XML converted to WiX's XML format. currently gnustep win32 is not using WiX for packaging, I hope this can be changed to use WiX. when TWW tools for win32 is ready, the conversion to use TWW will be easier. That sounds good. At here ftp://ftp.gnustep.org/pub/gnustep/binaries/windows/base-1.10.1/ Install-GNUstep-Development-Environment-1.10.1-bin.exe[Nov 5 2004] 11M the win32 installer has not been updated for a while. Anyone willing to take on this task ? Package GNUstep win32 using WiX. Regards tj _ Find sales, coupons, and free shipping, all in one place! MSN Shopping Sales Deals http://shopping.msn.com/content/shp/?ctid=198,ptnrid=176,ptnrdata=200639 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep packaging by TWW tools
I am not a software engineer so I can't help on swapping out xlib with cairo type of projects. but I want to have a FreeBSD type of packaging build system to maintain GNUstep. make gnustep-core-1.10 will unpack,patch,configure and build gnustep software components. It is very wasteful of compute/time resources to require everyone to compile gcc(with objc) if one is interested about running gnustep. GNUStep LiveCD is good but an easy way to install gnustep onto existing installed OS is even better. For now, I am using Solaris 10 intel for packaging gnustep by TWW tools (R1). The goal is to make installation of gnustep very easy across OS platform. My plan 1. prepare gcc-4.1.1 for Solaris 10 intel (U2, 06/2006 version) first and down port lower version solaris and sparc cpu. bash-3.00# /opt/gcc411/bin/gcc -v Using built-in specs. Target: i386-pc-solaris2.10 Configured with: /opt/build/gcc-4.1.1/configure --enable-nls --enable-threads --disable-maintainer-mode --enable-shared --enable-libgcj --enable-languages=c,c++,objc --datadir=/opt/gcc411/share --with-gnu-as --with-as=/opt/gcc411/i386-pc-solaris2.10/bin/as --with-local-prefix=/opt/gcc411 --prefix=/opt/gcc411 Thread model: posix gcc version 4.1.1 bash-3.00# uname -a SunOS b-solx86-10 5.10 Generic_118855-14 i86pc i386 i86pc bash-3.00# 2. package the gnustep core software(make,base,gui). 3. release package sources 4. Lobby gnustep development community to use TWW tool so TWW CPAM tool can help GNUstep's CPAD. This will be hard because asking people to switch to different tools using different processes. Goal: /opt/bin/pkg-inst gnustep-2.0, will install gnustep-core and gnustep apps automatically. will install gnustep and its depended software clusters. This is a hobby project and subject to my free time. References: R1. http://en.wikibooks.org/wiki/CPAM_with_TWW/User_Guide T.J. Yang _ Experience the magic of the holidays. Talk to Santa on Messenger. http://clk.atdmt.com/MSN/go/msnnkwme008001msn/direct/01/?href=http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
