Split miniaudio.h

[Krzmbrzl]

As of writing this, the miniaudio.h file has a size of 3.7MB. This is pretty huge for a single source file and in my opinion it makes it very, very hard to try to grasp the current implementation has one is simply blown away by the sheer amount of stuff happening in there.

I think for readability's sake it would be much better if the header was split into separate header and source files (not only how it is done in extras/miniaudio_split). For one I could imagine having separate .h and .c files for every supported audio backend.

I understand that having only a single header file that projects can include seems to be a feature of this project and here are a few options to retain this feature:

• Use a build tool to patch together all files into a single unified header file. That way folks could download the project, run the build tool and then use the combined header
• Add a script to generate the unified header. If written in something like Python, it should be possible to assemble the unified header on every OS
• Once of the above + always check in the unified header when doing a release. This seems to be essentially the reverse of what is currently done for miniaudio_split. It does have the disadvantage of duplicating code though.

[mackron]

This will never happen, sorry. I know that's a blunt response, but I just prefer it like this.

[Krzmbrzl]

May I ask what so consider to be the advantage of having everything in a single file?

[mackron]

It's just a subjective personal preference. I find it easier to find things when it's all just in one place, and it's just easier to manage the project generally (reviewing patches, adding the file to new projects, etc.) That's contrary to popular opinion, I know, but it's just the way I like it and it suits me and my development style.

[frink]

@Krzmbrzl @mackron I wonder if there is a way for both to have what they want...

Suppose that the main branch of MA is kept to one file like the BDFL wants. But also suppose that there are formatted comments // SECTION: node_graph // that would allow those of us who want to read the code as a spit file to do so. Then a simple shell script could be included that looks for those split points and generates the files that the rest of us want for easier readability. In addition, we could add a reversing script to allow us to edit separately but conglomerate them back to a single file. That way it doesn't break anything in the BDFL workflow, but at the same time does not force everyone else to use his workflow of editing 4MB text files. For clarity's sake we could even add the output of these scripts to .gitignore so that BDFL doesn't need to look at them.

What do you think. Could that work for you?

[frink]

I'm going to leave it with you @Krzmbrzl ...
We got from a frank "No" to a maybe...

If you can create the spitter/joiner and it's simple and cross platform you can have what you want.

Once you do that PR we can close this.

[Krzmbrzl]

#534

[Krzmbrzl]

I would prefer keeping the header only approach

I just wanted to clarify that this was never the intention of my request. You can still be header-only when splitting things up in multiple files.

[frink]

I understood it to be header only. Just you were suggesting to make it modular with multiple headers.

[Krzmbrzl]

I just realized my above comment is a bit ambiguous: What I wanted to say is that my intention never was to remove the header-only character of this library. So what you said was exactly my original intention.

[frink]

I noticed the PR was closed due to debate over implementation. That's sad, but probably the right call. Unless we can find a way to fit into @mackron's workflow the whole thing is pointless. I may try again on this in a few months. But I agree that debate is not productive.