This is the mail archive of the cygwin-apps@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: How to create a ksh93 package...


Fleischer, Karsten (K.) wrot

 > Absolutely. This holds for the following utilities:
 >
 >  basename cmp      dirname  head     mkdir    rev      tee 	
 >  cat      comm     expr     id       mkfifo   rm       tty
 >  chgrp    cp       fmt      join     mv       rmdir    uname 	
 >  chmod    cut      fold     ln       paste    stty     uniq 	
 >  chown    date     getconf  logname  pathchk  tail     wc
 >
 > The versions that can be used as builtins are in the cygcmd12.dll
 > However, if you use these as builtins with ksh one might want to
 > use the standalone versions from other shells, too. The standalone
 > versions are merely stubs that call the cygcmd12.dll.
 >
 > The ast-open package contains many more utilities that might
 > conflict with GNU utilities (find, for example) and other useful
 > stuff (e.g. cql, nmake, iffe).
 >
 > I'd prefer a seperate dir not hidden too deep in the tree, where all
 >  the ast utilities (including ksh) get installed, e.g.
 >  /usr/ast/ bin
 >            fun
 >            lib
 >            man

Bad.  With one exception, we've decided not to clutter the top level 
/usr directory with a bunch of package-specific subdirs.  (The exception 
is the 'autotool' tree, which acts as a home for automake-devel, 
automake-stable, autoconf-devel, autoconf-stable, libtool-devel, and 
libtool-stable.  And there was a lot of argument about it.)  BTW, I 
thought you weren't installing the man pages?

Maybe we need a top-level /opt directory?  OTOH, I see no need for 
/usr/ast/* instead of "ksh, and the DLLs go in /usr/bin; stub 
executables that are ksh-replacements for "standard unix tools" -- 
regardless of whether cygwin has "normal" ports yet -- go in 
/usr/bin/ksh/ or /usr/libexec/ksh/ or wherever.

 > The ksh93 package would make a symlink /bin/ksh --> /usr/ast/bin/ksh
 > so that ksh is available for everyone without changing the PATH.
 > The accompanying DLLs cygast54.dll, cygcmd12.dll, cygdll10.dll and
 > cygshell11.dll reside in /usr/ast/bin, too.

This is a bad idea.  You can't use symlinks for DLLs, and DLLs must be 
in the path -- so you need to put /usr/ast/bin (or /usr/bin/ksh/bin or 
/usr/libexec/ksh/ in the PATH somewhere.  But it needs to be at the END 
of the path for "normal" cygwin, and at the beginning of the path for 
"ksh-centric" usage.  Blech.  (okay, if .dll is in same dir as .exe, 
it'll work...but geez)

Why not let ksh be a full-fledged cygwin package?
/usr/bin/ksh.exe
/usr/bin/*.dll
/usr/libexec/ksh/*.exe
/usr/lib/*
(what is "fun"?)
and you already said you weren't installing the man pages...

 > Anyone who wants to use ksh with the standalone version of the
 > cygcmd12.dll commands would have to download another package and add
 > /usr/ast/bin to the PATH.
 > The remaining tools would go into yet another package.
 > (And we might want to have a developer package with import libs,
 > headers etc. but that's a different thing to be discussed later...).

/usr/include/*
/usr/lib/*

 > Regarding the sources,
 > I will build only with the full ast-open package which is about 8MB
 > compressed tar.
 > I cannot split up the sources into seperate archives that would
 > reflect the actual structure of the binary packages.
 > The source archive may be distributed, this is not the problem.
 > The problem is that I have a n:1 relationship between binary and
 > source packages.
 > How should I deal with this?

Use dummy -src packages, for now.  See ncurses/libncurses, 
gettext/libintl1, etc.

--Chuck


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