Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com Message-ID: <3CA33AC6.5000503@ece.gatech.edu> Date: Thu, 28 Mar 2002 10:46:14 -0500 From: Charles Wilson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Fleischer, Karsten (K.)" CC: "'cygwin-apps AT cygwin DOT com'" Subject: Re: How to create a ksh93 package... References: <200203281431 DOT g2SEVrO11438 AT dymwsm11 DOT mailwatch DOT com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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