cmake targets correlate to build configurations

[saterj]

An eclipse build has multiple build/debug configurations

This must be represented in cmake's generation.

[saterj]

You're forgetting the --generate flag.

While I haven't tried this. I don't know if there will be an overarching CMakeLists above the whole project.

I'll likely have to tie that all together as well as improve my test script.

[saterj]

So far I think there are two directions I can take this:

1. CMAKE_BUILD_TYPE meta generation
2. CMAKE Generator expressions

This could just be my inexperience showing, however. I think I want to try the latter and see if it has particular advantages over the first one.

[saterj]

So after refactoring a bit of the project.cpp files (I really hate the use of autos since my indexer couldn't determine the members of things)

I can see what this is doing

    map<string, cdt::configuration_t> artifact_configurations;

    vector<string> confs = cdtproject.cconfigurations();
    for(string& conf_name : confs)
    {
        cdt::configuration_t c = cdtproject.configuration(conf_name);
        cdt::configuration_t& a = artifact_configurations[c.artifact + to_string(c.type)];

We're finding all the configurations, and making a map of ${projName}{projType} to produce as a cmake target. _this is overwriting every cdt::configuration_t that we have_! I think this is gross and should be removed. we WANT multiple artifacts of the same output type in my group. But that's another issue.

Ultimately this for-loop is looping through every configuration, and it presently doesn't have a clause to add in environment variables or exclude folders. It's time to stop accepting features that don't translate into cmake!

[saterj]

This issue is a bit larger than a single issue can take. however we have environment variables that are evaluated upon the configuration chosen during the cmake call. So I'll mark this as win...