This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: astksh review (was Re: Pending package status (09 May 2003))


> I've just reviewed astksh properly and have only one 
> suggestion, it might 
> be a good idea to include build instructions and tools required to 
> re-build from source..apart from that it's looking great 
> (well the license 
> in the docs is an overkill :-)

The license text is shorter than GPL :-)
AT&T is a big concern with many, many lawyers and we can be happy that
they did release some of their software into the Open Source.

Regarding build instructions:
Well, everything's there already.

Follow the normal GNU tools instructions, configure/make:

$ ./configure
you didn't have to do that

So, guess what that means :-)

$ make
[...]

Here we go.
You don't need anything else.

The build process roughly goes like this:
- make hands over the build job to bin/package, the AT&T building and
packaging workhorse.

- first some scripts in src/cmd/INIT are checked: execrate (to work
around some bogosities with .exe suffix handling in cygwin), ignore,
mamprobe (compiler feature probing), silent and probe (will use
mamprobe). Then hurl (for downloading newer releases, can cope with
curl, wget and /dev/tcp shell semantics), iffe (perhaps comparable to
autoconf) as well as some other scripts.

- the build "view" is established. Everything that is being build goes
into an arch/cygwin.i386 tree (with bin, lib, include, fun and src
subdirs). On Intel Linux systems everything would go into
arch/linux.i386. Have a look at
http://www.research.att.com/~gsf/cgi-bin/download.cgi?action=list&name=a
st-ksh for supported architectures. (BTW, the cygwin package on that
page is not cygwin setup compatible).

- the scripts from src/cmd/INTI are copied to arch/cygwin.i386/bin

Now it gets interesting:

- mamake is built. mamake is a make derivative that understands MAM
(Make Abstract Machine) files. mamfiles only contain build scripts, as
when you're building from scratch, no timestamp checking or whatever is
done. AT&T nmake can output mamfiles and they have also instrumented GNU
make to output mamfiles. Look at the Mamfiles in the source tree to get
an idea.
- proto is built. proto is capable of turning ANSI C code into K&R code
for old compilers. The compiler is probed with the aformentioned probe
and mamprobe scripts.
- ratz is built. ratz is a replacement for tar+gzip, it is only able to
unzip and untar. Used in conjunction with package and hurl to download
and unpack new releases if your machine doesn't have tar or gzip.

Now all of these tools are in the build view arch/cygwin32.i386/bin dir.

- bin/package hands over to mamake and then feature testing with iffe
and compiling is done with the Mamfiles.


I build the release packages differently. I use the full ast-open
package, which comes with AT&T nmake.
I first build ast-open with

$ bin/package make

or

$ CC=gcc bin/package make ast-open

if gcc is not correctly recognized. In the ast-open case, nmake is one
of the first tools to be bootstrapped with mamake. Once it is up and
running, mamake is not used anymore.

Then I install ast-open into /opt/ast

$ bin/package install flat cygwin.i386 /opt/ast ast-open


After adding /opt/ast/bin to the PATH I have everything up to date.


I rebuild ksh statically then with

$ package make ast-ksh static=1 SHOPT_CMDLIB_DIR=1
PACKAGE_OPTIMIZE=space

The "static=1" takes care of linking everything statically.
"SHOPT_CMDLIB_DIR=1" causes the 35 UNIX tools to be builtins and
"PACKAGE_OPTIMIZE=space" is used for stripping the binary.

The cygwin setup compatible binary package and setup.hint can then be
generated with:

$ package write base binary cyg version=2003-04-22 ast-ksh

The source package with:

$ package write base source cyg version=2003-04-22 ast-ksh

The dummy "configure" scripts and the GNU makefile are generated on the
fly, too.

Some things will definitely change in future with this kind of build
procedure, e.g. PACKAGE_OPTIMIZE=space shouldn't really be necessary.
That's a case for the nmake global Makerules.mk.
Also, the "cyg" package type support is a bit rudimentary yet, it won't
package up dynamically linked ksh and dlls correctly now.

I hope I could give some insight. Some things looked like black magic to
me at first, too, two years ago.

Karsten


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]