Mail Archives: cygwin-apps/2002/03/28/10:44:03
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
- Raw text -