Post by Jens ElknerPost by Jens ElknerPost by Kurtis RaderThat is an extremely bold proposal. As you alluded to there is a bit of a
chicken and egg problem. Ksh93 source in its current form cannot be built
independent of large chunks of the AST code base. So to be able to build
It provides the basic stuff to be able to build ksh93 - see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/init-file-lst.diff
...
And as said: because there seems to be no ksh93 history, nothing gets
Post by Jens Elknerlost, if one starts with what has been initially released, i.e. the
files from 2012-08-01 (but of course not with all the bloat but only,
what is really needed) - e.g. see
http://iks.cs.ovgu.de/~elkner/tmp/ksh93/ksh-src-file.lst
I recognize that because Jens is German and thus English is not their
native language I may have difficulty understanding some of the points they
are making. But I'm pretty certain I have a good grasp of the dependencies
needed to build ksh93. And stating that "the INIT package is sufficient" is
sophistry that in no way negates my point.
Well, I think, a good engineer should at least read the READMEs bundled
with the software he/she is gonna change in a dramtic way. IMHO reading
related documentation is essential to do a proper work, understand the
SW and its build system at least at a basic level and avoids postulating
wrong assumptions again and again!
Post by Jens ElknerNotice that ksh-src-file.lst in the link above contains a large amount of
code from src/lib/libast, src/lib/libcmd, src/lib/libdll, etc. Which is
precisely my point. The fact that those files are dependencies of the
"INIT" package, and therefore do not need to be individually enumerated if
you simply state that building ksh93 only needs to depend on the "INIT"
package, is irrelevant to my point. Which is that huge chunks of the AST
code base is needed to build ksh93. That list also seems to be missing some
You are wrong, again! As said dozen? of times, the INIT and ast-ksh package
is all one needs to build ksh93! To understand this perhaps a little bit
better, I've digged out a Build script in my junk yard, which shows, how
I actually did it on linux systems in 2000+:
http://iks.cs.ovgu.de/~elkner/ksh.static/Build.sh
However, IMHO a good engineer reads the software's documentation
carefully, before starting to change it in a more or less dramtic way
and would have found out these more or less simple things by itself.
However, a good start (beside the bundled READMEs) would be e.g.:
https://web.archive.org/web/20150527152443/http://www2.research.att.com/~astopen/download/
or - available via the 'source install' menu point on the left side of
this page:
https://web.archive.org/web/20150527152549/http://www2.research.att.com/~astopen/download/gen/SOURCE.html
Post by Jens Elknerother dependencies that are needed, at least when not building on Solaris,
such as the src/cmd/msgcc and src/lib/libcodex directories.
Also, I didn't check but I'm betting there are items missing from that list
which are needed for the unit tests. Too, a lot of that code (e.g., the AST
malloc subsystem) should be replaced by the same facility provided by the
libraries of the operating system (e.g., libc). Thus eliminating the
dependency on the AST code that provides that functionality. Which allows
us to remove it from the AST source dependencies to build ksh93. Which in
turn reduces the amount of code that needs to be compiled from scratch when
building ksh93. And reduces the amount of code that has to be maintained to
keep ksh93 working.
Well, optimizing is good. But first understanding, what the current
build system is doing, is better. I'm also excited in what you are coming
up with, but when seeing your current work, I get very mixed feelings ...
Post by Jens ElknerP.S., I'm also confused by entries like "ksh/lib/package/ast-ksh.README" in
the file linked to above. They're not in the source tree and not generated
when I build ksh93. I suspect those are artifacts of building on Solaris
and thus irrelevant to this discussion.
Nope - as said, reading/understanding the docs of the software one is
going to mangle is usually one possible point of success. Wrt. the mentioned
wrong assumption you should 'bin/package --man' and optionally have a
look at lib/package/package.mk (and knowing, that a good instructor
wouldn't do this, I even give you the shortcut: lib/package/ast-open.README).
Last but not least I've already posted a script on github, which shows
the Q&D way to generate it (inkl. comments) - IIRC your comment was
"what I am supposed to do with that script ...". 'Reading it' is probably a
good answer ...
Have fun,
jel.
--
Otto-von-Guericke University http://www.cs.uni-magdeburg.de/
Department of Computer Science Geb. 29 R 027, Universitaetsplatz 2
39106 Magdeburg, Germany Tel: +49 391 67 52768