Hi Norm,
Thanks for the quick answer !
> > While looking at sfw gate, few questions came to my mind.
> >
> > 1) Why are usr/src/cmd/Makefile.targ and /usr/src/lib/Makefile.targ
> > different ? Libraries could also use the unpacking and patching stuff
> > from cmd/Makefile.targ.
> >
> {cmd|lib}/Makefile.targ originated in ON and have a series of different
> targets in them. There are a few targets in cmd/Makefile.targ that
> should probably move up to Makefile.master and be used by everyone. The
> unpacking and patching (and eventually download) targets come to mind.
exactly
> I know that when I integrated them into cmd/Makefile.targ, there was a
> conflict with something in usr/src/lib and that's why it isn't in
> Makefile.master yet.
If there is no CR for it, I'll create one. I think that we are closing
to silent period before opensolaris, so maybe it's not good time to push
those changes.
> > 2) Looking at usr/src/cmd/Makefile.targ, it seems that there's some work
> > on separating different package statuses and describing process how to
> > go from one status to another. For example .patched and .unpacked. Is
> > this somewhere documented ?
> >
> It's not documented and needs to be. I started working on templates for
> Makefile.sfw, METADATA, and packaging related bits a while back, but it
> seems like I never can get back to them.
I know that feeling :)
> I would like to complete them, put them out for review, document the
> various targets and get components to start moving to them.
Do you have some rough skim ?
make all = (download) -> unpack -> patch -> build -> post_build ?
make install = install
Makefiles can be incredibly powerful for this. Have you thought about a
way for package to override default action ? Afaik you can't delete
once defined rule in other makefile and if you create second rule, make
reports something like " Too many rules defined for target ..."
> You will also find a completely undocumented program in
> tools/pkgtemplate.pl. It can save you considerable time in packaging a
> component. If you build a component and install it somewhere
> (DESTDIR=/tmp/foo), you can use pkgtemplate.pl to generate package(s)
> automatically. It matches owner/group/mode with the package db on the
> system it's running on and does some other things to make life easier.
> You still have to audit the results, but it beats packaging 1000 files
> by hand.
I bet :) I'll check it out.
> > 3) Do we have some sort of wiki where we can document things ? I manage
> > several wikis in SWAN, but they are not publicly available. I think that
> > describing the package statuses is very important step to give all the
> > packages similar look.
> >
> This is something that I have suggested to management that we need to
> do. There is documentation on the gate machine, but it could stand some
> updating and I would love to see it outside in a Wiki so that others can
> get involved with it.
Creating a space on wikis.sun.com comes to mind.
http://wikis.sun.com/display/Help/How+To+Create+A+Wiki+Space
I don't have much experience with it, so hopefully it does not suck too
much.
> > 4) Why there's often touch to configure ?
> > gtar xzf XXX.tar.gz
> > touch configure
> >
> The touch is because the timestamp on configure is going to be older
> than the tarball timestamp.
Right
Thank you
--
Vlad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 193 bytes
Desc: not available
URL:
<http://mail.opensolaris.org/pipermail/sfwnv-discuss/attachments/20080925/aa139913/attachment.bin>
