Re: Supporting compression-less release builds

[Simon Burge <simonb%NetBSD.org@localhost>]

Hi Julio,

Julio Merino wrote:

> I'm currently working on a NetBSD-based embedded disk image and, while
> working on this project, the compression of various artifacts during the
> build gets in the way.  Compressing the sets and kernels is very visible
> the choke point of the build even on a fast machine, and is specially so
> when xz is in use.  But the thing is: compression is completely useless
> (for me) during the development cycle.

If you don't want the compressed sets in your development cycle can you
just use "./build.sh ... distribution" to skip generating the sets?

> I started with a simple idea to preserve current behavior yet allow me
> to disable sets compression:
>
> 1. Add a new COMPRESS_SETS tunable that takes no/gzip/xz as values.
>    The "no" value is what allows a user to disable compression.
> 2. Deduce the default value of COMPRESS_SETS with the same logic we have
>    today based on USE_XZ_SETS/USE_PIGZGZIP.  COMPRESS_SETS=no would never
>    be set by default today.
> 3. Retire USE_XZ_SETS.

A better control knob for sets wouldn't be unwelcome (IMO) :).

> The general idea would be to replace COMPRESS_SETS (not yet even committed)
> with a more generic COMPRESS_RELEASE (or similar name) and use that value
> wherever the release build wants to produce compressed artifacts.  Then,
> unify the many -0, -9, -n... flags that appear throughout the tree for gzip
> and xz in one single place so that, when compression is indeed enabled, we
> apply it consistently.

Note that we sometimes use an explicit compression method elsewhere
in the build (eg compressing kernels) that might differ from the
compression method for sets.

The way I read your proposal you seem to be suggesting "everything
in the build that needs to be compressed will be compressed with the
thing expressed by COMPRESS_RELEASE"; I'm pointing out that this might
break some things.  Now, whether or not the things that are compressed
differently are for a valid reason is a different question!  I can
think, for example, that an image that is designed to be dd'd to the
start of a memory stick might explicitly be compressed with gzip because
it might be easier to decompress a .gz file on a Windows box (I don't
know this to be the case, just using as a possible reason for preferring
a different compressor).

Cheers,
Simon.