Scriptable Supported Build Environments

[michaelvlach]

I strongly believe that Evoke should not hard-code its build environment specifics in C++ code. Let it be agnostic to the build environment it will use and use scriptable files (preferably JSON or something like that) to describe them that would be pulled in at runtime and used. For example I don't think it is a good idea to have the OS header files listed in the code.

I am talking from some experience because i have made something very similar to Evoke using Qbs. The Qbs has a JavaScript/QML based project files that allows you to do pretty much anything (including Evoke like project such as my qbs-autoproject). Qbs itself is using these QML files to know how to build on what platform, where to look for standard headers etc. etc. It is very flexible, transparent to the user and does not need recompilation every time one of the supported platforms gets an update (looking at Microsoft that just loves changing their paths). Users can even fix those themselves before you can release an update yourself.

That way you will also make it far simpler for contributors to help with supporting new platforms.

Given the current situation around Qbs I am considering my options and Evoke is currently my no. 1 to migrate to but I will need support for Windows and preferably the the #8 issue done before I would be able to do it. I have just disovered Evoke thanks to your talk at CppCon 2018 so I am glad I am not alone with this need for simple (or preferably "virtually" non-existent) build system.

[dascandy]

I completely agree on the configurability; if only for cross-compilers and Windows VS support it's a necessity. It's also a wish of mine to support adding new extension types to the build setup, but we'll have to see how far this can actually go without making the build system complex again.

Windows support has a strong preference from me (as I know that many use it), but I haven't used Windows for actual development since 2010 or so. Would adding Windows/MSVC support be something you're willing to pick up?

[dascandy]

Added a note to this effect in DESIGN.md .

[hl4]

Would it be a good idea to import a configure file parser library, such as toml-lang/toml or dropbox/json11?

[dascandy]

On one hand yes, on the other it makes it harder to build Evoke itself. There's a minor parser in here already which I think will be enough to get started with. By definition it should not need major configuration.

See also toolsets/ where part of this is already implemented. Ping to @Resurr3ction - is what's there now sufficient for you? It allows you to customize each part of a toolset, but not the structure. I've tried thinking how to generically extract the structure but it becomes really hard with the Modules discussions now and how to export transitive closures over public and private dependencies.

[dascandy]

@Resurr3ction I think Evoke now does all you need it to do. Toolsets can be configured. It does compilation database exports (-cp flag).