Repository: conan-io/conan-center-index

Issue:
[service] ninja windows binary outdated
there does not seem to be an up-to-date binary for ninja/1.10.0 on windows:
https://conan.io/center/ninja/1.10.0
https://bintray.com/conan/conan-center/ninja%3A_#files/_%2Fninja%2F1.10.0%2F_%2F3931d0d9c2d2df6551702798ae00538b%2Fpackage
https://github.com/turtlebrowser/turtlebrowser/runs/807869355?check_suite_focus=true#step:6:99

It's surprising because the last PR built correctly the 3 binaries: https://c3i.jfrog.io/c3i/misc/logs/pr/1985/1/ninja/1.10.0/

CC @patricia-gallardo


Discussion:
I've been investigating the PR logs... this is what I've seen:

![image](https://user-images.githubusercontent.com/1406456/85886735-e32d9d80-b7e6-11ea-882b-a254dca2d720.png)

but Windows is not built, it says:

```
￼============== Skipping configuration! ===============
```

Indeed, the profile chosen for Windows is:

```
[settings]
arch=x86_64
arch_build=x86_64
build_type=Debug
compiler=Visual Studio
compiler.runtime=MTd
compiler.version=14
os=Windows
os_build=Windows
```

and the ERROR in the outputs: https://c3i.jfrog.io/c3i/misc/logs/pr/1985/1/ninja/1.10.0/ca33edce272a279b24f87dc0d4cf5bbdcffbc187/

```
ERROR: ninja/1.10.0: Invalid configuration: Only MT MSVC runtime is supported
```

I'll copy/paste my comment here https://github.com/conan-io/conan-center-index/pull/1783#issuecomment-647428850: 

> Hi! Back here, first of all I want to apologize for introducing too much noise in my last comments (and more on this one). We've been talking about this issue because we had different opinions about these _installers_ and we need to agree on how we want to handle them in Conan Center.
> 
> We think that the best approach is as follows:
> 
> Note.- Here I'm referring to **packages that only contain executables**, if they contain libraries that are consumed by other packages then they should be managed as regular packages. So, let's talk about pure installers, packages with executables only.
> 
> 1. We want these packages to show that Conan is able to retrieve the same binary for different configurations, that you don't need to build from sources for every change in the configuration (if all you want is an executable).
> 2. These packages will list all the settings (`os`, `arch`, `compiler`, `build_type`) because all of them generate different artifacts, the package must compile and take into account all the combinations for these settings. We cannot raise a `ConanInvalidConfiguration` because it can block graphs with other packages in the _build_ context. User building from sources must generate the binary that corresponds to given configuration.
> 3. These packages will remove `compiler` and `build_type` from the package_id.
> 4. Conan Center CI will iterate the profiles in a given order and will build the binaries for the first configuration that returns every different package-ID. This will ensure that these packages will be compiled with `Release`, `static` and a known compiler version. `glibc` shouldn't be a problem after https://github.com/conan-io/conan-docker-tools/pull/204 (probably before that we will use the lower compiler version to minimize this error)
> 5. If these packages are required by others (because besides de executable it is generating other libraries) we will stop removing `compiler` and `build_type` in order to generate all the binaries again. Of course, we can consider other use-cases once they are known.
> 
> The main issue with this approach **right now is that we cannot guarantee the order CCI uses to iterate the profiles**, it means that we cannot be sure that the chosen configuration will be the one we expect. We are working on this, but it will take time (two weeks?). Meanwhile, we can stop this PR, or we can generate all these settings combinations and remove them afterward when the functionality required is implemented in CCI.
> 
> I hope this makes sense to everybody.
> 
> Thanks for pushing so hard!


**There is no workaround until be iterate the profiles in the given order**. Right now, moving the `ConanInvalidConfiguration` to the `build()` method is not the answer. It can happen that the chosen profile to build is one of the unsupported ones and no binaries will be generated.

Only solution right now is to generate all the binaries (all the valid configurations) and, once we iterate the profiles in order, we can recover those checks in the `build()` method.

Thanks for your understanding


ping @madebr @uilianries @SSE4 @danimtb  ⬆️ 
Do I understand correctly that the short term (temporary) solution implies not deleting settings.compiler from the package_id, even for executable only packages?

Resolving patch:
diff --git a/recipes/ninja/1.10.x/conanfile.py b/recipes/ninja/1.10.x/conanfile.py
--- a/recipes/ninja/1.10.x/conanfile.py
+++ b/recipes/ninja/1.10.x/conanfile.py
@@ -8,7 +8,7 @@ class NinjaConan(ConanFile):
     license = "Apache-2.0"
     url = "https://github.com/conan-io/conan-center-index"
     homepage = "https://github.com/ninja-build/ninja"
-    settings = "os", "arch", "compiler"
+    settings = "os", "arch", "compiler", "build_type"
     exports_sources = ["CMakeLists.txt", "*.patch"]
     generators = "cmake"
 
@@ -29,9 +29,6 @@ def source(self):
         os.rename("ninja-%s" % self.version, self._source_subfolder)
 
     def build(self):
-        if self.settings.compiler == "Visual Studio":
-            if self.settings.compiler.runtime != "MT":
-                raise ConanInvalidConfiguration("Only MT MSVC runtime is supported")
         for patch in self.conan_data["patches"][self.version]:
             tools.patch(**patch)
 
@@ -44,10 +41,6 @@ def package(self):
         cmake = self._configure_cmake()
         cmake.install()
 
-    def package_id(self):
-        del self.info.settings.compiler
-        del self.info.settings.build_type
-
     def package_info(self):
         self.env_info.PATH.append(os.path.join(self.package_folder, "bin"))
         self.env_info.CONAN_CMAKE_GENERATOR = "Ninja"


Test patch: