(Maybe) allow a way to specify the generator via an environment variable

[staktrace]

Right now cmake-rs seems to default to VisualStudio as the generator if the rustc target is msvc. However in my particular use case I would like to use Ninja. Ordinarily, the user of cmake-rs (in this case the build.rs script in servo-freetype-sys) would just set .generator("Ninja") and that would be fine. However that will change it for all consumers of servo-freetype-sys instead of just for my environment.

What I would like to do is add some sort of env var that I can set that will set the generator to be Ninja. But I'm unsure if the env var should be read from cmake-rs or from servo-freetype-sys. @alexcrichton Thoughts?

On the one hand I'm leaning towards doing it in servo-freetype-sys because it's a smaller change there. But on the other hand if I have a crate that depends on multiple sub-crates that all build stuff with cmake, it kind of makes sense to just put it in cmake-rs since the environment that's doing the build will have the same build tools available (in my case, Ninja) for all the sub-crates, and having to modify each sub-crate seems like a waste.

[alexcrichton]

Perhaps a variable could be added here like try_ninja? That way we could bake in any Ninja-specific logic and consumers could opt-in to using ninja-if-available?

Either that or putting it in servo-freetype-sys sounds good to me!

[staktrace]

Editing title to be a little more clear. The fundamental problem I guess is that the crate using cmake might be deep in the dependency tree from the top-level crate being built. And the build systems available in the environment are determined at that top level. So that's the level that should be able to control which build generator cmake uses. This seems like a textbook example of what environment variables are for.

(Edit: sorry, didn't see your reply before posting this, for some reason I didn't get a notification...)

Regarding your try_ninja variable suggestion, this sounds like it would (a) add some complexity to cmake-rs and (b) then require immediate users like servo-freetype-sys to set the variable? based on (c) some environment variable? Not totally clear to me that's better, or maybe I'm misunderstanding.

[alexcrichton]

Oh I'm just thinking that if ninja is installed and a build script is whitelisted to work with it then there's no need to use the native build system, we could just always use ninja. Ninja probably doesn't work by default with most projects though, which is why I'd imagine that an opt-in might be necessary

[staktrace]

Ninja probably doesn't work by default with most projects though, which is why I'd imagine that an opt-in might be necessary

Ah, I was assuming that if one generator (e.g VisualStudio) works then others (e.g Ninja) would work too. I figured that if that's not the case then it's a CMake bug. But if my assumption is wrong then yeah, what you're saying makes sense in that individual cmake-rs users should provide some way to indicate "these generators are the ones that are known to work with this project, use whichever is available". Your try_ninja variable suggestion is a specific instance of this that would solve my problem but maybe a more general mechanism would be better.