"Roger A. Faulkner" wrote:
> > Roland Mainz, a community member who is doing the engineering work
> > for the ksh93 integration project, has some questions regarding this flag
> > day.
> > I'm cc-ing Roland and the ksh93-integration-discuss at opensolaris.org
> > mailing list.
> >
> > Roland's workspace is currently based on build 37, but I will
> > be creating a workspace from the source on the current onnv-gate
> > and incorporating his changes.
> >
> > Thanks,
> > April
> >
> > Roland's questions:
> >
> > - Can I reuse the "mapfiles" generated from the *.spec files in the
> > current build (B37) and simply rename them to "mapfile-vers" ?
>
> Yes, that's how I did it. (You have to add the license/copyright notice.)
> Actually, you get 4 different mapfiles from the old spec files:
>
> spec/amd64/mapfile # from an i386 build machine
> spec/i386/mapfile
> spec/sparc/mapfile # from a sparc build machine
> spec/sparcv9/mapfile
>
> Hopefully, these will be identical (modulo sorting within each version)
> If so, you only need one new mapfile, common/mapfile-vers
Erm... is there any other "common" directory for these files except
"common/" ? Currently the AST ("AST" = "Advanched Software Technology",
more or less the superset on which ksh93/libshell is based on (libshell
is ksh93 made available as shared library - in our case /usr/bin/ksh93
is just a ~~5k wrapper which directly calls into libshell)) sources live
here.
The idea is that you can simply % rm -Rf lib/libshell/common/
lib/libdll/common/ lib/libast/common/ lib/libpp/common/ #
(lib/libcmd/common/ is an exception here since it is a merge of Solaris
libcmd and AST libcmd) and repopulate it from the AST sources and still
get the same results.
IMO it would be better if we had another subdir for the "mapfile-vers"
files...
> If there are small differences among the 4 mapfiles, please
> create a common/mapfile-vers with all the common stuff and
> separate <isa>/mapfile-vers files for the <isa>-specific stuff.
> (See usr/src/lib/libproc for a simple example)
Ok...
BTW: Why were the C prototypes dropped ? I know the CTF stuff contains
similar informationi but I thought the explicit listing in the *.spec
files was an attempt to catch accidental API changes (by comparing the
compiled prototypes against the prototypes defined in the *.spec
file...) ?
> > - Do you expect any problems using the new scheme if the
> > build machine is running build 37?
>
> No problem. One of my build machines is running build 23.
Ok...
> > - Would you be interested in reviewing the changes for the transition
> > from *.spec to "mapfile-vers" ?
>
> Sure. Whan you're ready, let me know.
Ok...
... Thanks! :-)
BTW: Is it "legal" to generate the "mapfile-vers" files during build
time ? The current set of *.spec files for ksh93/AST were generated
using scripts from the AST includes with minor adjustments by hand - but
this could be fully automated on demand.
----
Bye,
Roland
P.S.: Another, more general question (CC:'ing Mike Kupfer
<mike.kupfer at sun.com> for that): Is there any other future flag day
planned in the two months which will to similar tree-wide changes (I
just want to make sure that I don't get caught totally unprepared again)
?
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
