astksh review

[Glenn Fowler]

On Wed, 21 May 2003 20:58:17 -0400 Charles Wilson wrote:
> >>There is no problem with the regular configure/make (i.e., 
> >>building the
> >>default configuration of the package).  However, if I wanted to, say,
> >>twiddle with the source and turn some features on/off, or 
> >>experiment, or
> >>even, say, insert debug printouts for some bug that manifests 
> >>itself when
> >>running shell scripts, it would be much easier to do so with 
> >>pdksh -- I
> >>think I understand most of the source (haven't looked at it 
> >>in a while).

> >>As an aside, it would be great if certain features/defines in the code
> >>were turned on/off with configure's "--enable-*"/"--disable-*" options
> >>(not sure if they are now, sounds like they aren't).

> People, let me introduce you to a "gift horse."  Please stop inspecting 
> its teeth.

> Karsten and others have done a lot of work to accomodate the cygwin 
> packaging standard.  It is *extremely* disrepectful for us (the cygwin 
> community, as it were) to then insist on *internal* changes to the 
> product itself.

> e.g. "Stop using nmake and this really confusing Makefile system.  Use 
> autoconf"

> That is NOT helpful -- nor does it belong on this list.  We're talking 
> about packaging ast-ksh so that it can be installed on cygwin using 
> setup, and conform to our packaging rules.

> Those rules say nothing about requiring autoconf.  There's a tacit 
> assumption that cygwin packages should be buildable on a cygwin system 
> without additional, non-official cygwin packages -- but no requirement 
> that any *particular* cygwin tool (like autoconf) be used.  (ast-ksh 
> satisfies the build-on-stock-cygwin "rule", but not the 
> thou-shalt-use-autoconf "rule")

> ast-ksh uses a Makefile-driven build system.  It is not autoconfed.  It 
> never will be autoconfed.  And if it WERE to be autoconfed, that 
> discussion would belong over on the ast-ksh mailing list, because you're 
> talking about massive overall changes to the upstream package, not 
> simply cygwin-specific porting tweaks.

> (FWIW, I vote "yes" on this package, as is)

> --Chuck

thanks Chuck

I started composing a response a fews days ago and got sidetracked,
but it was along the same lines:

The cygwin astksh package does what it advertises -- it builds ksh93 on
cygwin.  The source is all there, but the build environment is mainly
for bootstrapping, not development.

If you want to twiddle the source and do incremental builds then
download and build the ast-base package in /opt/ast, following the
generic source instructions.  After it installs you can run the ast
nmake from any directory that contains a Makefile.  nmake takes
care of recursive subdir ordering.

For those who equate different with painful: get the aspirin out.
Source miners will have to step out of all that is gnu -- configure
automake autoconf libtool.  The main difference is that the ast
Makefiles are source -- all config-type generation, prerequisite
scanning, conditional selection, local compilation conventions, etc.,
happen as a direct consequence of running the ast nmake.  Detailed
discussion is welcome at

	ast-users@research.att.com

Finally, to reinforce Karsten's reply, we won't retrofit automake etc.
We have source configuration managment in place that has basically the
same form now as it did in 1990.

-- Glenn