Re: [Tack-devel] all of Ack-5.5 under Linux

[<u-...@ae...>]

On Wed, Jun 20, 2018 at 07:59:00PM +0200, David Given wrote:
> Re build tools: unfortunately the ACK is a really complex thing to build
> with lots of code generation and dependencies between components. The old
> build system didn't even try to track any of this stuff and relied on a
> hard-coded build order and single-threaded builds; but it was impossibly
> slow and impossible to understand, and didn't really achieve correct builds
> anyway. It was completely unable to be modified to support parallel builds.
> Hence the succession of new build systems.

I see. Fortunately it is not exactly "impossibly slow" on a relatively modern
processor and a well-performing file system. It takes less than 3 minutes
to do a full build from scratch here.
OTOH it does not seem to be meant/capable to do partial rebuilds.

Parallel builds bring an additional degree of complexity,
that's why I feel fine without them.

> I'm actually on the verge of giving up on make completely; it's essentially
> unable to do correct builds no matter how hard you try (try to build
> something which produces multiple output files some time!).

I would say go ahead. Make has it own niche but is hardly the right
tool for complex projects.

Even Ack's "scripts which builds scripts" are easier to analyze than
a corresponding tree of Makefiles, because they do not [have to] implement
exhaustive dependency resolution.

I wouldn't mind fully lua-based build tools, because I have got ack-built
lua and hence it is in the same "maintenance complexity domain".

> Re mach vs plat: mach contains CPU architectures, plat contains machine
> targets. Each plat depends on a single mach, but each mach may be used by

What is a "machine target"? Guessing:
"a combinations of a CPU and an OS syscall API"?
This is more or less what Ack-5.5 "mach" is, that's why I asked.

Then a target implementation implies a CPU-specific code generator
(which in your setup falls under "mach"? good)
and a libc implementation, possibly consisting of three parts,
 OS-generic,CPU-specific        <= a candidate for reuse by reference
 OS-specific,CPU-generic        <= a candidate for reuse by reference
 OS-specific,CPU-specific
right?

The reusable parts do not logically "belong" to any "machine target"
so for clarity should have their own place.

It would help if the source would consistently reflect the above.

Afaics that's why the current structure is hard to manage,
it does not make these relations sufficiently explicit.

> any number of plats. (Although not all the platform-specific stuff has been
> moved out of mach yet.)
> 
> Re libc problems: I don't know whether this is present in 5.5, but I
> wouldn't be surprised if it did. The problem is that the libc depends on
> many, many symbols which don't have prototypes by just importing them with
> extern. It's particularly keen on calling leading-underscore versions of
> system calls, so the implementation of system() actually calls _execl() to
> do the work. If the syscall library doesn't implement _execl() and only
> implements execl() then everything will appear to work until you try to
> actually *use* system(). I think the only complete syscall libraries are
> minix and em. (If you look in
> https://github.com/davidgiven/ack/blob/release-5-6/mach/minix/libsys you'll
> see that each symbol is defined twice.) (Also, it took me ages to find the

Of course. I removed this extra redirection level while porting minix
libc for ackpack but this _stuff is intact in Ack-5.5 so it works as
expected by the authors.

> em syscall library because it only exists in K&R C; it's in
> https://github.com/davidgiven/ack/tree/release-5-6/lang/cem/libcc/mon and
> the last change was in 1993. I think the phrase 'creakingly old' applies
> here.)
> 
> This only became apparent with em because ass doesn't work like led and
> tries to resolve all symbols when it links, rather than just the used ones.

Yes happened to notice this while building something to emXX, had to
remove some unused declaration iirc.

Keep going David!

Regards,
Rune