On Wed, 25 Sep 2013 19:26:27 +0200 Irek Szczesniak wrote:
> On Wed, Sep 25, 2013 at 6:40 PM, Glenn Fowler <[email protected]> wrote:
> >
> > On Wed, 25 Sep 2013 18:31:43 +0200 Irek Szczesniak wrote:
> >> On Wed, Sep 25, 2013 at 12:39 AM, Roland Mainz <[email protected]>
> >> wrote:
> >> > Hi!
> >> >
> >> > ----
> >> >
> >> > Attached (as "astksh20130913_md5sum_compat1.diff.txt") is a patch
> >> > which fixes an incompatibility between AST md5sum(1)&&co. and GNU
> >> > coreutils md5sum(1)&&co. fixes.
> >> >
> >> > There are three major differences which caused hiccups for 3rd-party
> >> > scripts:
> >> > - GNU coreutils md5sum/sha1sum/sha224sum/sha256sum default to text mode
> >> > - GNU coreutils use a " *" before the file name to indicate binary
> >> > mode and " " to indicate text mode... the AST hash utilities used
> >> > only a single blank " " instead.
> >> > - "-t" means "text mode" for GNU coreutils while AST used this for
> >> > "total"
> >> >
> >> > * Notes:
> >> > - GNU and AST *sum(1) utilities now have identical output and seem to
> >> > be 100% compatible with each other
> >> > - On platforms which do not implement |O_BINARY| and |O_TEXT| the
> >> > change only affects the seperator (" "/" *"(=new) vs. " "(=old)).
> >> > Portable applications can use [[:space:]]+ in egrep(1) to make sure
> >> > they can match the hashes against both the old and new versions of AST
> >> > *sum(1)
> >> > - The output *intentionally* changes only for utilities matching the
> >> > shell pattern "*@(md5|sha@(1|224|256|384|512))sum". This is done to
> >> > maintain compatibility for cksum(1) and sum(1)
> >> > - AST does not have a sha224sum(1) utility (yet) ... need to talk to
> >> > Glenn about this
> >
> >> Roland and Glenn: Roland added entry points for sha1sum(1),
> >> sha2sum(1), sha256sum(1), sha384sum(1) and sha512sum(1) but they do
> >> not appear in /opt/ast/bin. Could you check why this happens, please?
> >
> > do you have $INSTALLROOT/bin/nmake in your build tree?
> No, I only imported ast-ksh into my git (laziness). However I think
> the root cause is that the script which creates the entries for
> /opt/ast assumes one builtin == one source file, right?
no, that may have been the case a while ago, but now all libcmd source
is grep'd for b_*() prototypes and that is used to generate cmdlist.h
which is a file that with
CMDLIST(foo)
for each b_foo() defined in the libcmd source -- as source files are
added or modified in src/lib/libcmd cmdlist.h will be updated
users of <cmdlist.h> must first define the CMDLIST(name) macro
this is how ksh93 sets up its builtin table
the nmake Makefile glues this together
in src/cmd/builtin <cmdlist.h> is itself sed'd to generate the list of
builtins that must be installed in $INSTALLROOT/bin
again the nmake Makefile glues this together
it was a bit complicated to set up
but now it just does the right thing
as b_*() symbols are added (or deleted) <cmdlist.h> is updated
and ripples through the rest of the build
ast-base is the smallest package with nmake
install that and "bin/package make" will bottstrap build it
and then use it for the rest of the build
you will also need nmake to build any ast plugins (runtime lodable shared libs)
pax sort and ksh use these
also, using the mail I sent tina, you can cd into any subdir in $INSTALLROOT/src
and run "nmake install" and it will update everything in that dir and below
bin/package make does that from $INSTALLROOT/src
nmake checks the combination of makefiles to determine the build order
add new dirs with Makefiles under $PACKAGROOT/src and the $INSTALLROOT/src
build will pick them up and build them in the proper order
_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers
