Splitting source file/s for better readability

[tansy]

I kindly suggest to split source file (pigz.c) into separate files for better readability and, let's call it compatibility, with *nix source convention. Split in two categories:
documentation and source itself.
By documentation I mean license, change log, to-do list, and stuff, that resides in pigz.c, and by source I mean splitting it into smaller, categorized pieces. I was thinking about three, maybe four:

1. main loop, usage and this kind of functions,
2. multi threading
3. de/compression
4. maybe file/system functions.

I actually attempted to do that with documentation; it can be seen here (it's emporary tar.bz2 ball), and out looks like this:

.
./ChangeLog
./LICENSE
./Makefile
./README
./TODO
./doc/
./doc/pigz.1
./doc/pigz.info
./doc/pigz.pdf
./doc/pigz.spec
./pigz.c
./try.c
./try.h
./yarn.c
./yarn.h
./zopfli/
 

With pigz.c didn't dare to be honest, but I would say that scrolling through 5k lines of code is difficult and tiresome.

[madler]

I will consider it, but you would still have 5K lines of code to slog through.

[madler]

By the way, the .spec file is a build file, not documentation. It needs to be with the source.

[tansy]

Even moving documentation and all that stuff, out of pigz.c is good move. You may insist with license but that should be in separate file if it applies to the files other than source itself.

And yes, You're right about .spec file, I didn't register that.

[tomek-szczesny]

Well, actually yarn.c is a separate file already (for threading), but I kinda agree it's a bit intimidating to read through pigz.c for the first time. It may be beneficial from the educational perspective to divide pigz.c into smaller chunks.
That's just a humble opinion though, I am merely the one that tries to learn here.