This is the mail archive of the
cygwin-apps@cygwin.com
mailing list for the Cygwin project.
Re: How to create a ksh93 package...
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: "Fleischer, Karsten (K.)" <kfleisc1 at getrag-ford dot com>
- Cc: "'cygwin-apps at cygwin dot com'" <cygwin-apps at cygwin dot com>
- Date: Thu, 28 Mar 2002 18:25:44 -0500
- Subject: Re: How to create a ksh93 package...
- References: <200203281622.g2SGMrO28807@dymwsm11.mailwatch.com>
Fleischer, Karsten (K.) wrote:
> I'd prefer the name /usr/libexec/ast then.
> Would other executables that are not stub executables but alternative version to existing commands go there, too?
> AT&T have own versions of dd, df, du, ed, expand, file, find, grep, od, pr, sed, sort, strings, etc.
> The other tools that have no Cygwin pendant, like cql, ditto, iffe, look, mamake, nmake, ratz, etc., they would go into /usr/bin?
>
> There are > 150 DLLs, executables and scripts altogether
!!!!!
I thought we were talking about a shell, here, not a total and complete
rewrite of the entire GNU/BSD/Linux environment! :-)
> in the full ast-open package /bin directory, and I have to distribute them into two different directories?
> No thanks.
> Chances that I would overwrite something existing by error are high.
Yeah, in that case most DLL's and EXE's should go in /usr/libexec/ast/*
or /usr/libexec/ast/bin/* or whatever.
*EXCEPT* for the specific DLLs that are necessary for proper -- but not
accelerated -- operation of the ksh.exe itself. Those DLLs, and
ksh.exe, should go into /usr/bin. (C'mon, it's not that hard, after
'make install' to 'mv $MY_SHORT_LIST $inst/usr/bin' within your build
script...
BTW, are you following the proper naming scheme for DLLs on cygwin?
cygfoo-N.dll (or cygfooN.dll), import lib libfoo.dll.a, static lib
libfoo.a? (Never mind, 'cygcmd12.dll' -- looks like you are...)
>> > 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
>>
>
> I know.
Also, symlinks mean that the shell cannot be started by windows; windows
must then use the full (deep) 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)
>>
>
> That's why I wanted to put all the ast .exe files into a seperate */bin dir along with the DLLs.
I understand the reasoning. But relying on the runtime loader's
"samedir" behavior seems like a bad idea to me...but perhaps not...
>>Why not let ksh be a full-fledged cygwin package?
>>/usr/bin/ksh.exe
>>/usr/bin/*.dll
>>/usr/libexec/ksh/*.exe
>>/usr/lib/*
Okay, how about this, then:
the minimal runtime package; contains just ksh.exe, the ABSOLUTELY
necessary DLLs (cygast54.dll, cygcmd12.dll, cygdll10.dll,
cygshell11.dll?), ksh.1, and basic documentation:
ksh-VER-REL:
/usr/bin/ksh.exe
/usr/bin/cyg???.dll
/usr/man/man1/ksh.1
/usr/doc/ksh/....
/usr/doc/Cygwin/ksh-x.y.z.README
/usr/info/ksh.info?
/etc/postinstall/ksh.sh <<< runs install-info...
then, there's the "acceleration pack" which contains only the loadable
functions (and the dlls on which they may subsequently depend), etc.
requires: cygwin ...
ksh-accel-VER-REL:
/usr/libexec/ast/bin/*.dll (but not the ones in the basic ksh pkg)
/usr/libexec/ast/fun/*
/usr/libexec/ast/man/?
/usr/libexec/ast/info/?
/usr/doc/kst-accel/* << maybe just a pointer into /usr/doc/ksh/
/usr/doc/Cygwin/ksh-accel-x.y.z.README << "go look here..."
requires: ksh ...
next, there's the full-blown ast package, which contains all those other
(GNU replacement) executables and such.
ksh-ast-VER-REL:
/usr/libexec/ast/bin/*.exe
/usr/libexec/ast/man/? <<< more stuff
/usr/libexec/ast/info/?
/usr/doc/ksh-ast/*
/usr/doc/Cygwin/ksh-ast-x.y.z.README
requires: ksh-accel ksh ...
and finally, there's the devel package, which contains the include files
and import/static libs:
ksh-devel-VER-REL:
/usr/libexec/ast/include/
/usr/libexec/ast/lib/*.dll.a
/usr/libexec/ast/lib/*.a
/usr/doc/ksh-devel/*
/usr/doc/Cygwin/ksh-devel-x.y.z.README
requires: ksh-ast ksh-accel ksh ...
>>/usr/include/*
>>/usr/lib/*
>>
>
> We might have conflicts here with headers, too. I have to check.
Since it looks like ksh implements a whole 'nother set of
implementations of common functions (in its various libraries) -- yeah,
that seems pretty likely to clobber some existing or future stuff.
Better segregate these under /usr/libexec/ast too...
--Chuck