You can subdivide build dependencies into several groups:
- tools necessary to execute the build, like make, gcc and a lot of the other dependencies included in build-essential
- development libraries necessary to build and link binaries like what is in zlib1g-dev and the rest of your *-dev list
- runtime libraries (which you didn't list any of) which are typically dependencies to the *-dev packages.
- external support executables as well as data files used at runtime
The first two you can remove after the build is complete. The third list are typically shared libraries, but there may be support files in that too. This is a much harder list to determine.
You might be able to remove the dev libraries and then pick through what autoremove wants to remove to figure out how many of those are critical shared libraries.
Or you can pick through your built target and run ldd on the executables and libraries and figure out what the necessary packages are for the found shared libraries. Note that not all of these will be found with in the above suggested autoremove list! Also, this won't find libraries that are detected at runtime and dynamically loaded rather than actually linked at compile time.
Picking out packages with needed support files might be even harder, as without careful analysis. I'd hate to remove them only to find things that crashed without them, assuming you manage to hit that code path while you are testing rather than in production!
In short, there's no easy clean answer. It takes careful analysis, good knowledge of all your applications, and maybe still some trial and error.
