This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: XEmacs on cygwin [Was: Re: missing file FOO.dll]




> -----Original Message-----
> From: Charles Wilson [mailto:cwilson@ece.gatech.edu] 
> Sent: Saturday, 1 June 2002 2:18 AM

> Robert Collins wrote:
>  
> > XEmacs uses a fork of setup. Someone who cares might like to suggest
> > that they update their fork to a more recent codebase, or 
> ... provide a
> > setup.ini for cygwin users.
> 
> 
> Well, their fork of setup does more than just unpack the 
> packages.  It 
> also mucks with the registry, sets up shortcuts, etc.  (I know, our 
> setup does those things too).
> 
> Now, if the grand "data-driven" scheme is complete, THEN
>    a) if XEmacs updates their setup.exe to the recent codebase AND
>    b) they create a "package" that handles those items (but it can't 
> rely on cygwin tools to do its magic, because they uuse the same 
> setup.exe to install the purely native XEmacs; the end user might not 
> have any cygwin tools installed)
>    c) we figure out how to handle the relocation problem (*)

This is all quite straight forward should it be desired. Setup's code
base is 'getting there'. Some notes to prove it :}...

a) This is only needed if they want to add dependencies to *their*
version of setup.exe. I.e. it knows what to do for them, but can be
pointed at a cygwin mirror to get libpng.
b) This is needed to allow the cygwin.com setup.exe to install Xemacs
correctly, i.e. to supplant their forked version. Mind you, it's trivial
to do: command line tools to do the registry stuff are already around,
and I bet that mingw ports of those tools are trivial :]. Likewise for
shortcuts.
c) * Anything that is a guideline is a matter of policy. Setup will
simply follow the package. Unless Xemacs was contributed as a package,
this is not an issue. (And I'm not suggesting it should be contributed
as a package).
   * We can trivially add a tag for setup.ini called 'prefix' that tells
setup where to place a package. i.e. 'prefix: /usr' results in a tarball
containing bin/foo extracting to /usr/bin/foo. This is a generally
useful tag (consider packages that belong in /usr/local for testing...
Just package them as bin/ lib/ etc/ containing tarballs, and then prefix
them to /usr/local, followed by /usr when production ready. This should
also take care of the lisp packages.
   * We can -consider- multiple roots, but I don't have a glib answer
for this one just yet.

Andy - if you are interested in merging stuff, or making cygwin's setup
a closer fit to your needs (for whatever reason), join in now :}.

Rob

 
> (*) We pick a cygwin root, and install everything under that 
> -- but the 
> packages must follow certain guildlines: /usr, /etc, etc.  
> They pick an 
> XEmacs root and install everything under that -- and have few 
> guidelines.  Currently, the XEmacs tarballs themselves are 
> packaged as:
>    bin/i686-pc-cygwin/
>    lib/xemacs-21.4.6/
>    man/
> But the lisp packages are packaged as
>    pkginfo/
>    lisp/
>    lib-src/
>    etc/
>    info/
>    man/
> And xemacs' setup "knows" to unpack those under
>    <xemacs root>/xemacs-packages/
> Just like our setup "knows" to unpack -src tarballs under
>    <cygwin root>/usr/src
> 
> To sum up: this harmonization won't be easy -- even if the 
> XEmacs folks 
> are inclined to do so, which I doubt.
> 
> --Chuck
> 
> 
> 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]