Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-apps-owner AT cygwin DOT com
List-Subscribe: <mailto:cygwin-apps-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-apps/>
List-Post: <mailto:cygwin-apps AT cygwin DOT com>
List-Help: <mailto:cygwin-apps-help AT cygwin DOT com>, <http://sources.redhat.com/lists.html#faqs>
Mail-Followup-To: cygwin-apps AT cygwin DOT com
Delivered-To: mailing list cygwin-apps AT cygwin DOT com
Message-ID: <3CA3A678.502@ece.gatech.edu>
Date: Thu, 28 Mar 2002 18:25:44 -0500
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2
X-Accept-Language: en-us
MIME-Version: 1.0
To: "Fleischer, Karsten (K.)" <kfleisc1 AT getrag-ford DOT com>
CC: "'cygwin-apps AT cygwin DOT com'" <cygwin-apps AT cygwin DOT com>
Subject: Re: How to create a ksh93 package...
References: <200203281622 DOT g2SGMrO28807 AT dymwsm11 DOT mailwatch DOT com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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