[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNUstep packaging by TWW tools
From: |
T.J. Yang |
Subject: |
Re: GNUstep packaging by TWW tools |
Date: |
Wed, 27 Dec 2006 06:35:10 -0600 |
From: Richard Frith-Macdonald <address@hidden>
To: T.J. Yang <address@hidden>
CC: address@hidden
Subject: Re: GNUstep packaging by TWW tools
Date: Wed, 27 Dec 2006 10:59:51 +0000
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