Re: [dev] Re: mksh build system

From: Thorsten Glaser <>
Date: Sat, 3 Aug 2013 11:37:39 +0000 (UTC)

Anselm R Garbe dixit:

>Are you willing to accept a Makefile/ approach for mksh? This
>My current approach for all userland tools is creating a custom
>Makefile/, simply because the existing, autoconf or
>whatever approach sucks.

(jump to tl;dr at the end of the mail if needed)

I agree that they all suck. I know exactly why and where mksh’s sucks, but it’s the lesser evil for me (as upstream)
considering mksh’s target “market” (including really ancient
and really weird OSes).

The problem at hand is: upstream definitely needs the automatic
discovery of flags method because no downstream (not even distro
vendors) usually know exactly what to put in there.

One thing you *can* do with mksh, and which I regularily do for
MirBSD and Android, and which laffer1 regularily does for MidnightBSD,
is to have generate you a that contains the
results from all the tests. You can then either include that from
a Makefile or (which is what we currently do) move the definitions
into the regular Makefile/

The CPPFLAGS you end up with are dependent on the OS, OS version
and mksh version, so you’d have to run this step once when you
import a newer mksh version. But it’s pretty decently automated,
so it’s not that hard.

As an example, running this
        tg_AT_hugh:~/build $ mksh /usr/src/bin/mksh/ -M
on MirBSD, after exporting CC and CFLAGS, yields:

# Makefile fragment for building mksh R47 2013/07/26

PROG= mksh
MAN= mksh.1
SRCS= lalloc.c eval.c exec.c expr.c funcs.c histrap.c jobs.c lex.c main.c misc.c shf.c syn.c tree.c var.c edit.c strlcpy.c
SRCS_FP= /usr/src/bin/mksh/lalloc.c /usr/src/bin/mksh/eval.c /usr/src/bin/mksh/exec.c /usr/src/bin/mksh/expr.c /usr/src/bin/mksh/funcs.c /usr/src/bin/mksh/histrap.c /usr/src/bin/mksh/jobs.c /usr/src/bin/mksh/lex.c /usr/src/bin/mksh/main.c /usr/src/bin/mksh/misc.c /usr/src/bin/mksh/shf.c /usr/src/bin/mksh/syn.c /usr/src/bin/mksh/tree.c /usr/src/bin/mksh/var.c /usr/src/bin/mksh/edit.c /usr/src/bin/mksh/strlcpy.c
OBJS_BP= lalloc.o eval.o exec.o expr.o funcs.o histrap.o jobs.o lex.o main.o misc.o shf.o syn.o tree.o var.o edit.o strlcpy.o
INDSRCS= emacsfn.h sh.h sh_flags.h var_spec.h
NONSRCS_INST= dot.mkshrc $(MAN)
NONSRCS_NOINST= Makefile check.t
CC= mgcc
CFLAGS= -O2 -pipe -std=gnu99 -Os -fweb -frename-registers -Wformat -Wstrict-aliasing -Wbounded -fwrapv -fno-align-functions -fno-align-labels -falign-loops=4 -falign-jumps=4 -march=i486 -mpush-args -mpreferred-stack-boundary=2 -momit-leaf-frame-pointer -fhonour-copts -Wno-deprecated-declarations -fno-asynchronous-unwind-tables -fno-strict-aliasing -fstack-protector-all -Wall -fwrapv

# not BSD make only:
#VPATH= /usr/src/bin/mksh
#all: $(PROG)
#$(PROG): $(OBJS_BP)
# $(CC) $(CFLAGS) $(LDFLAGS) -o $_AT_ $(OBJS_BP) $(LIBS)
# $(CC) $(CFLAGS) $(CPPFLAGS) -c $<

# for all make variants:
check_categories= shell:legacy-no int:32

# for BSD make only:
#.PATH: /usr/src/bin/mksh
#.include <>

The only important line of this is the CPPFLAGS= one.
You’ll need from and including -DMKSH_BUILDSH up to
and including -DMKSH_BUILD_R={someversionnumber}.

As long as it’s one operating system, such as just,
the defines should stay the same – currently even across
varying CPU architectures.

As I use #if HAVE_FOO, defining the “unset” ones to 0
explicitly is really recommended.

Oh, a file is also generated… but all it does is
calculate check_categories (also in the then
run this:

perl $srcdir/ -s $srcdir/check.t -p $objdir/mksh \
    -v -C ${check_categories// /,}

You’d want to run this at least once.

tl;dr: mksh/ supports generating a
already. You can just ${vcs} add then ${vcs} commit the
generated file whenever you import a new mksh version,
as it should stay the same for across CPUs even.
You can then use regular (even parallel) make to build
the actual executables.

‣ automatic running of -M during preparation, then
  parallel building with stock make
‣ committing of generated file, globally parallel make build
  (the file is pregenerated with the correct cross-compiler
  in CC, correct CFLAGS, etc. since it’s system-dependent)

Hope that’s okay for you,
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.	-- Rob Pike in "Notes on Programming in C"
Received on Sat Aug 03 2013 - 13:37:39 CEST

This archive was generated by hypermail 2.3.0 : Sat Aug 03 2013 - 13:48:06 CEST