Easy way to configure build's features and libraries

[cancerberoSgx]

I think there's place to configure which libraries to include in the build using environment variables so is easier to generate a smaller wasm in case features /formats are not needed.
a working build without any library weights 2mb and still is able to perform useful things and support many formats. On the other side, with all libraries (and including freetext to support text&fonts) its size is around 7mb. If more and more features/libraries are added being able to somehow configure the build without editing the script could be important.

I would like to prototype something around this so we can discuss. Note that I've never done this and probably there are tools that simplify this but initially I will just use shell if statements and variables. Initially there will be a variable to enable/disable each of the current supported libraries. Also I will try to play with IM configure flags see if more things can be disabled or enabled without adding libs.

There will be an "official" set of features enabled, and that build will be used for running tests. Later we can try to declare test dependencies to selectively run tests on each build.

Also later we can discuss if/how distribute build with different configurations or tools to easily generate/download them.

Also I will research if ALLOW_MEMORY_GROW can be disabled so users can configure also this and the memory size. after seeing the build warning so many times I want to test if such optimizations are really worth it.

Finally I will try to see if emscripten ports for zlib, libpng and others can be used as I used freetype in 'text' branch so we can remove submodules for those and simplify the script. See #32

@KnicKnic I know you want to use Native.Magick build in the future and probably this is not reusable there, but I really want to research on this and test if minimal wasm works. I really don't have much expertise in this area perhaps you know a tool or method for this (I won't learn a new language). Perhaps writing the build using JavaScript with something like shelljs and run it with node could allow us to have less errors and escalate this better? I know shell scripts but I would feel more comfortable being able to declare data in json and building / executing commands and variables with javascript string templates / TypeScript interfaces to declare and document all the settings....do you have any strong opinions? Thanks!

[KnicKnic]

Ideally the build system would not be where you configure different apps. Ideally you would do it on systems as dynamic libraries. This is currently supported by ImageMagick, I statically linked them because itwas easiest for webassembly. Emscripten does support dynamic link see https://github.com/emscripten-core/emscripten/wiki/Linking.

I wanted to use Native.Magick build because it didn't need to fork ImageMagick. I would prefer to not have multiple people solve the same build issues for WebAssembly Imagemagick. Currently the Native.Magick build system doesn't produce working webassembly. I would prefer to use cmake as Native.Magick is trying to do. I originally didn't use cmake because I didn't spend the time to figure out it.

anyways an abandoned fork attempting to do this is at #48

[cancerberoSgx]

Aja! - dynamic loading of libraries would be ideal, but I suspect hard to accomplish. On the other side, offering a couple of builds to users, one minimal and another with all libraries seems more doable. Right now I'm trying the later

I think I already mention it, but my problem was that Native's build is not including IM utilities so, the build only supports C/C++ APIs but not convert/identify commands which is the current API this project and magica exposes. I tried to include utilities but fail. Without them it won't work with the current design.

[cancerberoSgx]

Closing this since it's being discussed at #52