Mitten.O wrote:@adrian_broher: How would deeper dependence on cmake eliminate the need for an SDK? I am not aware of any library downloading capabilities in cmake.
You're not up to date then:
http://www.kitware.com/media/html/Build ... ke2.8.html Add an external project cmake macro to your project which tells cmake how to build the dependency and it will do everything to reliable reproduce a build environment with fitting dependencies rendering the SDK useless.
Geoff the Medio wrote:??? I have no idea what you're talking about here... If there were no MSVC or XCode project files, the situation for Eclipse would be exactly the same as you describe... (?)
I said:
2) on the contributor side to create working build environments that work with all the required settings. This prevents potential developers from contributing.
You asked:
I don't see how providing more and simpler to use build environments would prevent developers from contributing...
I replied:
There is no Eclipse build environment on Windows, so people who want to use Eclipse on Windows and don't want to use MSVC they MUST BUILD the project file and the dependencies FROM SCRATCH. Building the project file and the dependencies from scratch is HARD, VERY HARD and just a very few people have the knowledge, determination and time to create a WORKING project file and dependencies instead of doing the actual contribution. People will say "Screw it, I'm not wasting my time with that." instead of adding something to the project. Now how does this NOT prevent developers from contributing?
How do you even come to the response quoted?
This is a relatively infrequent situation; exceptions don't invalidate the basic point.
The point is that this situation can be prevented entirely if we wouldn't maintain multiple build environments.
Aside from the "right folder" part being moot, the SDK also includes all the dependencies precompiled. But yes, I do say knowing how to use the CMake GUI, selecting the correct build system, source, and working directories, building a build system, then opening that build system is more work / harder than just opening the premade project file / solution.
See the response to Mitten.O. The precompiled dependencies are useless because the fit only for exactly one build environment per platform. The SDK needs to be versioned to fit to a specific range of commits. When dependencies change you need to rebuild the SDK and users need to download it after finding the right SDK for the project version the want to play with or develop for. This is harder than just download the code, run cmake and compile the project.
The point of the SDK is so that most developers don't need to do this. If there wasn't an SDK, every dev would have to find the right new dependency versions, download and figure out how to build them, and then make sure CMake and its derived build systems can find them. Having the SDK doesn't prevent someone from doing this if they want, but the extra work this would require would prevent many devs from contributing.
[…]
So that most devs don't have to collect and build all those dependencies.
Again: the whole point of my suggestion is to remove ALL these burdens from the the contributors/users and us developers, not shifting them from us developers to the contributors/users.
Sure... but then they'd have to do all the work that the SDK has done for them. (The point of the SDK is not to save my or Vezzra's time...)
What work are you talking about here?