Re: [Tack-devel] an old i386 code generator bug?

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

On Sun, May 08, 2016 at 12:19:07AM +0200, David Given wrote:
> The ACK's build system is awful. But it's way better than the last one.
> And you should see the one *that* replaced.

:)

> The problem is that the ACK is big and very complex. The dependency
> graph is insanely complicated, with lots of tools building source code
> for other tools which are used to build tools. This isn't anything which
> a modern, sane build system can't cope with, but we don't have one ---
> we have make.

In my opinion lot of this complexity comes from keeping everything
together, instead of splitting and documenting the interdependencies.

> I would *love* to switch to a hermetic build system, because that would
> iron out all the remaining dependency bugs. The best one I've found is
> bazel, but I don't think that requiring uses to download a 135MB
> self-extracting archive plus a JVM would really fly.

:D

Ackpack builds with minix make which is 50k when statically linked.

> I think that the current approach, which tries to build everything in a
> single pass, is a poor one, and we'd be much better off with multiple
> make passes: one to build the platform-independent things, tools etc;
> and then each platform is built in its own pass. That would avoid the

This sounds similar to what I am doing, with the difference that
I keep the source files and build results for each part separately
so that there is no single package but a number of related ones.

> need to generate make rules on the fly. We lose a lot of parallelism and
> builds will be a lot slower but it would be so much simpler.

Parallelism gives limited gains and has costs. The bigger the system is,
the more expensive and less reliable it is to check interdependencies
on-the-fly.

I am pretty sure that splitting the package into smaller ones makes
partial rebuilds (i.e. during development) faster, despite the lost
parallelism.

The time needed for a full rebuild is hardly important, this is not to
be done often enough to justify optimization.

Cheers,
Rune