On Mon, Nov 06, 2017 at 08:46:30PM -0800, Kurtis Rader wrote: > On Sun, Nov 5, 2017 at 4:53 PM, Jens Elkner <jel+...@cs.uni-magdeburg.de> > wrote: > > > On Sun, Nov 05, 2017 at 02:27:14PM -0800, Kurtis Rader wrote: > > > That 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 > > > > No, wrong! As said, just building the INIT "package" is sufficient: > > 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 > > lost, 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! > Notice 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 > other 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 ... > P.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 _______________________________________________ ast-developers mailing list ast-developers@lists.research.att.com http://lists.research.att.com/mailman/listinfo/ast-developers
