[My initial reply to this was blocked by opensolaris.org for being
too large, because I had attached the generated install-sfw file to
it. Here it is again, without the bloat]
Paul,
Thank you for taking the time to look at this. It's
greatly appreciated!
The answer to some of your questions is covered in the readme
file I pointed at in my original message. (Note that its
name has changed from README.SUNWemacs to README.SUNWgnu-emacs,
a result of having completed the trip through PSARC):
http://cr.opensolaris.org/~alib/emacs/usr/src/cmd/emacs/README.SUNWgnu-emacs.html
Please have a quick look there, and let me know if it still doesn't make sense.
I'll provide answers to your questions inline below.
> === Start of Comments ====
>
> 1. usr/src/cmd/Makefile
> & usr/src/pkgdefs/Makefile
> This looks as though it needs resyncing with the
> gate, so it doesn't look as though you are try to
> delete stuff.
The SFW gate is always changing, so it's not surprising that a static
webrev will become out of date. I've just freshened it again.
>
> 2. usr/src/pkgdefs/SUNWgnu-emacs-*/pkginfo.tmpl
> You don't need the version number on the NAME= lines
The rule for that wasn't clear to me, so I put it in both NAME and
DESC. I'll consult with our packaging folks here and fix it as
necessary. Thanks for reminding me to follow up on that.
>
> 3. usr/src/cmd/emacs/Makefile.sfw
> This invokes '$(SH) install-sfw' but that is
> not in your webrev.
It's a generated file --- there's a rule for it in Makefile.sfw.
Emacs is different from lots of stuff in SFW, in that it has to be built
4 (or 6 with GTK) times in order to harvest all the needed binaries. To manage
this, and the sheer number of files involved, I use a local proto directory
to stage the results.
There's a script (tools/process_manifest.pl) that takes the manifest file,
and generates both install-sfw, and all of the svr4 packaging lines,
automatically.
Since emacs ships with ~2800 files, this approach gives me some leverage, and
reduces the risk of mechanical error.
I'll attach a copy of the install-sfw to this message so that you can see
what it looks like.
> 4. usr/src/cmd/emacs/augment/man/man1/*.1
> Were these part of the original src tarball, if so
> why have you not used them from there rather than
> having your own copy of them?
Everything under augment is something missing from the emacs tarball
that I am supplying. (See the README)
I'm going to offer those manpages back to the emacs developers.
Whether they take them or not remains to be seen.
>
> 5. src/cmd/emacs/Makefile.sfw
> Lines 142 to 147 '.... make install'; does the
> package's Makefile allow you to use something
> like 'make DISTDIR=$(LPROTO) install' rather than
> having to set prefix, bindir, etc. ?
I think it does. However, the resulting default emacs layout
isn't what we want for Solaris. A default emacs creates
a libexec directory, whereas I wanted it to be /usr/lib/emacs.
I felt that being explicit here was a better course.
>
> Is INSTALL_ROOT root (/) or is it the proto area?
> (I forget); if it's the proto area shouldn't it be
> root (/) ie. where it really runs from.
INSTALL_ROOT is the place where emacs expects to find itself at
runtime. So, it's normally root (/). When you're bringing up
a new version, and want to experiment with it without installing
it, it can be convenient to define it to be the proto. However, it
would be a mistake to ship it that way.
Look at how it's used in tools/build_emacs --- a NULL value gets
turned into root (/).
>
> === End of Comments ======
>
Thank you once again for taking this on.
- Ali
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: install-sfw.head
URL:
<http://mail.opensolaris.org/pipermail/sfwnv-discuss/attachments/20080807/b459c179/attachment.ksh>
