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
