IDE plugin tasks should not be created/visible if they are not useful

[big-guy]

On Windows and Linux, it doesn't make sense to be able to generate Xcode IDE metadata.
On macOS and Linux, it doesn't (currently) make sense to generate Visual Studio metadata.

For visual-studio, we partially remove some tasks incidentally because we cannot build some binaries. But we keep a lot of the other tasks that do something (visualStudio, cleanVisualStudio, filter/project file generation tasks), but nothing useful.

Related to #472

Older, longer description of this problem (from the software model) is below.

@philmcardle commented on Thu Oct 27 2016

In a script in which the configured toolChain isn't available to Gradle, the visual-studio plugin won't generate the solution and lifecycle tasks.

Expected Behavior

The visual-studio plugin should either always generate all tasks, regardless of the available toolchains, or report a useful error.

Current Behavior

On a machine without GCC, with the following code

apply plugin: 'cpp'
apply plugin: 'visual-studio'

model {

    toolChains {

        gcc(Gcc) {

        }

    }

    components {

        TestProject(NativeLibrarySpec) {

        }

    }

}

gradle tasks --all output is

Build tasks
-----------
assemble - Assembles the outputs of this project.
build - Assembles and tests this project. [assemble, check]
clean - Deletes the build directory.
TestProjectSharedLibrary - Assembles shared library 'testProject:sharedLibrary'.
    linkTestProjectSharedLibrary - Links shared library 'testProject:sharedLibrary'
TestProjectStaticLibrary - Assembles static library 'testProject:staticLibrary'.
    createTestProjectStaticLibrary - Creates static library 'testProject:staticLibrary'

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'test'.
components - Displays the components produced by root project 'test'. [incubating]
dependencies - Displays all dependencies declared in root project 'test'.
dependencyInsight - Displays the insight into a specific dependency in root project 'test'.
help - Displays a help message.
model - Displays the configuration model of root project 'test'. [incubating]
projects - Displays the sub-projects of root project 'test'.
properties - Displays the properties of root project 'test'.
tasks - Displays the tasks runnable from root project 'test'.

IDE tasks
---------
cleanVisualStudio - Removes all generated Visual Studio project and solution files

Verification tasks
------------------
check - Runs all checks.

Other tasks
-----------
TestProjectDllVisualStudioFilters
TestProjectDllVisualStudioProject
TestProjectLibVisualStudioFilters
TestProjectLibVisualStudioProject

When it should be the following (output created by either changing the toolChain for VisualCpp or after installing gcc)

Build tasks
-----------
assemble - Assembles the outputs of this project. [TestProjectSharedLibrary, TestProjectStaticLibrary]
build - Assembles and tests this project. [assemble, check]
clean - Deletes the build directory.
TestProjectSharedLibrary - Assembles shared library 'testProject:sharedLibrary'.
    linkTestProjectSharedLibrary - Links shared library 'testProject:sharedLibrary'
TestProjectStaticLibrary - Assembles static library 'testProject:staticLibrary'.
    createTestProjectStaticLibrary - Creates static library 'testProject:staticLibrary'

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'test'.
components - Displays the components produced by root project 'test'. [incubating]
dependencies - Displays all dependencies declared in root project 'test'.
dependencyInsight - Displays the insight into a specific dependency in root project 'test'.
help - Displays a help message.
model - Displays the configuration model of root project 'test'. [incubating]
projects - Displays the sub-projects of root project 'test'.
properties - Displays the properties of root project 'test'.
tasks - Displays the tasks runnable from root project 'test'.

IDE tasks
---------
cleanVisualStudio - Removes all generated Visual Studio project and solution files
TestProjectVisualStudio - Generates the Visual Studio solution for native library 'TestProject'.
    TestProjectDllVisualStudio - Generates the 'TestProjectDll' Visual Studio solution file.
    TestProjectDllVisualStudioFilters
    TestProjectDllVisualStudioProject
    TestProjectDllVisualStudioSolution
    TestProjectLibVisualStudio - Generates the 'TestProjectLib' Visual Studio solution file.
    TestProjectLibVisualStudioFilters
    TestProjectLibVisualStudioProject
    TestProjectLibVisualStudioSolution

Context

Discovered while writing code to allow my Gradle scripts to intentionally select a specific toolChain. Doesn't block anything, just, confusing initially.

Steps to Reproduce (for bugs)

Code above.

Your Environment

Gradle 3.1
Windows 10 Version 1607

---

@philmcardle commented on Thu Oct 27 2016

I've found another instance of this, which I can't work around, which might eventually block me.

Environment: Gradle 3.1, Windows 10 Version 1607, now with MinGW installed.

apply plugin: 'cpp'
apply plugin: 'visual-studio'

model {

    toolChains {

        gcc(Gcc) {

        }

    }

    platforms {
        x64 {
            architecture "x64"
        }
    }

    components {

        TestProject(NativeLibrarySpec) {
            targetPlatform 'x64'
        }

    }

}

This, again, doesn't create the full set of Visual Studio tasks. This is a bit of a nuisance for us as we're looking at (but haven't got to yet) cross-compiling both locally (MinGW / VM with shared disk / Windows Linux Subsystem) and also remote (Visual C++ for Linux) and it would be appreciated if the Visual Studio plugin would just generate the IDE projects and solutions.

---

@lacasseio commented on Thu Oct 27 2016

Thanks for reporting the limitation between Visual Studio and Gcc. The visual studio integration is limited when it comes to your current scenario. There is some idea in discussion in how this can be improved in order to provide a better solution. The IDE, especially for C++, is opinionated on certain modeling which make it the integration harder than it seems.

We decided not to take route of generating native IDE projects and solutions because of the complexity when it comes to mapping generated source set, pre-build, pre-link and post-link steps. The current solution is by far perfect and because of this it's harder to integrate current Visual Studio plugins. It's best to seek a solution in Gradle as you will be able to reuse the logic on local developer machine as well as CI server. That been said, share your various usage scenario with us so we can take them into account during future design improvement.

---

@philmcardle commented on Fri Oct 28 2016

I suppose I should clarify, my issue is that the Visual Studio plugin won't create some of the IDE tasks when Gradle knows that it can't build that target, but it's not consistent and it's not explained - i.e. it creates the Project and Filters tasks, but not the Solution task or the encompassing lifecycle tasks.

I would like the Visual Studio plugin (or any IDE project generator) to work independently from whether the target binaries are buildable, or, if it must be tied to whether to something is buildable, then it shouldn't generate only half the tasks - it should generate none of them.

I'm not expecting Gradle's Visual Studio plugin to generate Visual Studio projects with VS-equivalent build steps (pre-build, pre-link, etc.) - we're implementing all the build logic in Gradle, however, almost all of our developers will want to work in Visual Studio, so it's paramount that I'm able to generate something.

I've already written quite a lot of gradle (and will write more yet) to modify the generated Visual Studio projects, but it's much easier when I can depend on Gradle having created the projects in the first place :)

---

@lacasseio commented on Fri Oct 28 2016

Thanks for reporting this issue, we will consider your scenario in the improvement work for Visual Studio integration.

[big-guy]

@ghale is this situation any better with the recent changes to the visual studio plugins?

[ghale]

I would expect so. Previously, we would only generate a project if one of the binaries were buildable.
With the most recent changes, we create the project regardless of whether binaries are buildable or not, so I believe it would address the use case detailed above.

There has been some discussion, though, around the use case of "binary X is never buildable" (e.g. I only build shared variants of a library). This is different from "binary X is not buildable on this machine" (e.g. no supported platform toolchain). For the former, there is no reason to ever generate the metadata as it would simply not be used (and it only serves to clutter the solution and slow things down). We had discussed possibly using the buildable flag to tell us whether or not we should generate the metadata, but we currently have no way to distinguish between the two cases. Given the use case described in this issue, I don't think setting the binary as buildable would be a viable solution (at least in its current form), so we'll probably need to come up with something better for that.

In any event, I would expect that the latest changes to Visual Studio metadata generation should address the problem described in this issue.

[big-guy]

It looks like we still always generate a visualStudio lifecycle task, clean task and filter/project tasks, regardless of whether or not we can actually use the tasks.

I'll reword the issue a bit to make that clearer.