Add platform config as params to BMK

[GWRon]

For now specific platform configuration (like for android) have to be stored in "custom.bmk".

This is not project specific. Assume you have two android projects requiring different SDK/Target/...
How to tackle that for now?

• BMK uses it's TBMKglobals to store this information
• "custom.bmk" sets up some globals there
• BMK uses an application based settings file for "AppSettings" (which are not taken into account when requesting "globals")

So there are multiple things possible:

• add new commands to BMK (--android-home="/PATH/TO/SDK/android-sdk-macosx")
• add new command to BMK (--settings="/PATH/TO/custom.settings")
• extend "globals or default" to "globals or (appsettings or default)"

Why do we need such a thing? It would be not a good idea for an IDE to alter the "custom.bmk" (think of multithreaded compilation ...). Yet it is up for the IDE (or a "project manager") to provide the needed data to compile a specific project.
Having the option to use a custom settings file (or something overriding "custom.bmk" temporarily) means an IDE (or developer) could store a project specific variant and then compile with that.
Having new commands ("--android-home") means to have not to rely on (temporary) external files but as we already do that way with "ld.tmp" that seems to be no biggy. Also having new commands means you have to provide a command for every option (except you have --setting "name"="value" --setting "othername"="othervalue") which would lead to a lack of flexibility.

I am not sure what export targets need custom "compiler information".
For android we might also think of adding information regarding "deployment" (will add a new issue for this).

So what would I prefer? A custom settings file whose URI is to pass (so allows tmp files and the likes). Also I assume it is kind of the most simplest solution to the problem.

What do you think about this?

[woollybah]

Wouldn't it work to use the app-specific bmk file?

[GWRon]

It could work.... But as said this is loaded for now into "AppSettings" not "globals".

Also: if once an IDE tackles stuff like "available devices" it should be able to pass this without touching a potentially user-handmade-app.settings file.

So passing another file with a custom param seems the way to go. Maybe even in a "before" and "after" manner (to keep or override user settings).