Ali Bahrami writes:

> > One annoying issue you might need to be aware of, which I found when I
> > built emacs 23.1 myself:
> > 
> >     GTK+ Emacs 23.1 on Solaris 10/11 ignores all X toolkit options
> >     http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=4330
> > 
> > Could you please check if your build is affected as well?  Perhaps it is
> > possible to identify the fix from CVS Emacs and apply it?
> 
> I'll have a look. No promises, but that does sound annoying...

Indeed it is: now you have to manually position the Emacs window instead of
setting the geometry on the command line.  X Resources aren't an option
here since they affect every instance of Emacs, which would overlay each
other.

> >   Why set SFL and DST three times only to override the value immediately?
> 
> install-sfw, the changes to Targetdirs, and the prototype files, are all
> mechanically generated by a perl script I wrote to help me manage the 
> thousands
> of files in an emacs distribution. I run 'ls ls -a1FR', and then turn it into

Shouldn't this be added to the sfwnv consolidation, so the next Emacs
maintainer doesn't have to reinvent that wheel?  If you did, you could omit
the generated files and avoid the massive diffs in the webrev.

> a manifest file that I feed to that script. Here's what that part of the 
> manifest
> looks like:
> 
>      dir_sys          *               *       usr/gnu/share
>      dir_bin          *               *       usr/gnu/share/man
>      dir_bin          *               *       usr/gnu/share/man/man1
>      file             emacs           *       ctags.1
>      file             emacs           *       etags.1
> 
> Where the columns are:
> 
>      item                package     platform    file
> 
> So the output you see is just a reflection of non-optimized script output.
> Those lines have more meaning to the Targetdirs and packaging output.
> Harmless, but ugly. I'll trim out the excess lines.

Fine, thanks.

> > * I see you build emacs with --with-gif=no.  Would it be possible to change
> >   this, at least in the future?  I suppose there could be legal problems
> >   with shipping libgif, though.
> 
> Solaris doesn't have the necessary GIF library, and providing it is outside 
> the
> scope of what I'm prepared to do. The previous emacs didn't have GIF support
> either. Configure needed the explicit option this time --- I'm not sure why.

Understood, it was just a suggestion.  Having to specify --without-gif is
probably worth an upstream bug report, though.

> However, the moment that library appears, I'll be happy to use it. I'm not
> really sure why that hasn't already happened.

No requesters so far, legal problems?  Probably time for an RFE.

> > * Would it be possible to replace explicit version numbers in the
> >   prototype* files by variables?  This would massively reduce the size of
> >   the diffs in the future.
> 
> It would, but I would have to get the SFW tools that process the packages to
> expand them, and it doesn't seem worth it. I've put my faith in the fact that

I don't think so: you could just set the variables in pkginfo.tmpl and use
them in prototype_*.

> the files are mechanically generated, and so anything that the GNU package
> delivers will be faithfully put into the Solaris package. I'm therefore
> leveraging the effort put in by the GNU emacs developers to deliver the right
> files, and as such, not very concerned about the size of the package diffs.

I was just concerned about having to review massive diffs and perhaps
missing the needle in the haystack with all the noise.  Perhaps this will
be easier to resolve in IPS, though.  I have no idea how this would look,
though.

        Rainer

-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University

Reply via email to