BUILD parameter causing error

[TheJare]

I followed the docs here http://docs.conan.io/en/latest/howtos/vs2017_cmake.html to create a simple Visual Studio sdl2 project using SDL2/2.0.7@bincrafters/stable

It compiles and runs fine in x86 Debug, but any other configuration complained that there was no prebuilt package, and suggested I needed to try "--build SDL2". I added the BUILD missing parameter to the conan_cmake_run() line, but with this the error is more mysterious:

1> PROJECT: Installing D:/Dev/vs/sdlconancmake/conanfile.txt
1> Requirements
1>     SDL2/2.0.7@bincrafters/stable from local
1>     libiconv/1.15@bincrafters/stable from conan-center
1> Packages
1>     SDL2/2.0.7@bincrafters/stable:dc9c05d50f7ee47ac10a455d7e592a61d7c75f59
1>     libiconv/1.15@bincrafters/stable:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7
1> 
1> libiconv/1.15@bincrafters/stable: Already installed!
1> ERROR: Error while trying to get recipe sources for SDL2/2.0.7@bincrafters/stable. No remote defined

The error is the same regardless if I do BUILD missing or BUILD SDL2

Complete CMakeLists.txt

project(Example CXX)
cmake_minimum_required(VERSION 3.8.0)

find_package(OpenGL)

# Download automatically, you can also just copy the conan.cmake file
if(NOT EXISTS "${CMAKE_BINARY_DIR}/conan.cmake")
message(STATUS "Downloading conan.cmake from https://github.com/conan-io/cmake-conan")
    file(DOWNLOAD "https://raw.githubusercontent.com/conan-io/cmake-conan/v0.9/conan.cmake"
                "${CMAKE_BINARY_DIR}/conan.cmake")
endif()

include(${CMAKE_BINARY_DIR}/conan.cmake)

conan_cmake_run(CONANFILE conanfile.txt
                BASIC_SETUP CMAKE_TARGETS
                BUILD SDL2)

set(exetype)
if(MSVC)
  set(exetype WIN32)
endif(MSVC)

add_executable(example ${exetype} example.cpp)
target_link_libraries(example ${CONAN_LIBS} ${OPENGL_gl_LIBRARY})

conanfile.txt:

[requires]
SDL2/2.0.7@bincrafters/stable

[generators]
cmake

And example.cpp, contents are irrelevant.

[TheJare]

I was using conan 1.0.0. I updated to latest 1.1.1 and the error is basically the same but slightly different. Reading it again, I guess it may be trying to get the sources and the bincrafters package is not providing them. This would be a problem on their side not conan!

PROJECT: Installing D:/Dev/vs/sdlconancmake/conanfile.txt
1> Requirements
1>     SDL2/2.0.7@bincrafters/stable from local cache
1>     libiconv/1.15@bincrafters/stable from 'conan-center'
1> Packages
1>     SDL2/2.0.7@bincrafters/stable:dc9c05d50f7ee47ac10a455d7e592a61d7c75f59
1>     libiconv/1.15@bincrafters/stable:6cc50b139b9c3d27b3e9042d5f5372d327b3a9f7
1> 
1> libiconv/1.15@bincrafters/stable: Already installed!
1> SDL2/2.0.7@bincrafters/stable: WARN: Forced build from source
1> ERROR: Error while trying to get recipe sources for SDL2/2.0.7@bincrafters/stable. No remote defined

[memsharded]

In my case it was failing to build locally because it had hardcoded the "Ninja" generator for cmake, which I hadn't installed. But removing that, it built locally.

I'd say in your case the issue is a different one. Maybe you had the "bincrafters" repo to fetch the package recipe, then you removed the repo before building it? If you do that, the recipe doesn't know where to retrieve the sources from. And as the sources are retrieved only if you need to build from sources, that is the error message that I can read: Error while trying to get recipe sources for SDL2/2.0.7@bincrafters/stable. No remote defined. Together with the SDL2/2.0.7@bincrafters/stable from local cache, I suspect that it is that the bincrafters repo was removed. Try removing the package with conan remove add the bincrafters repo and try again.

Thanks for your feedback!

[TheJare]

I had added the bincrafters repo a while ago. When I created this small project, conan had no problem fetching this package and building the x86-Debug config. As soon as I switched to any other config (Release or x64) the error showed up.

The problem turns out to be more interesting. When I originally wrote the project, the package name in conanfile.txt was sdl2/2.0.7@bincrafters/stable, with sdl2 in lower case, as officially listed in https://bintray.com/bincrafters/public-conan/sdl2%3Abincrafters/2.0.7%3Astable

With the package written like this, I compiled the project first time and ended with the following error:

1> sdl2/2.0.7@bincrafters/stable: Build folder d:\Soft\conan-home\data\sdl2\2.0.7\bincrafters\stable\build\dc9c05d50f7ee47ac10a455d7e592a61d7c75f59
1> ERROR: Requested 'sdl2/2.0.7@bincrafters/stable' but found case incompatible 'SDL2'
1> Case insensitive filesystem can't manage this

I didn't really understand what this means, but anyway, I changed sdl2 to upper case in the conanfile.txt and the project compiled fine in x86-Debug. However, the project could not build in any other configuration, which originated this issue report.

So, it appears, if I write the package in conanfile.txt in lower case, the package downloads and builds itself (in the currently selected configuration), but then the project that uses this package it can not be built (case-insensitive error). If I then change conanfile.txt to upper case, the project now builds. As soon as I change build config, the package in upper case can't be found.

So, workaround is, temporarily set package in conanfile.txt to lowercase so the package is downloaded and built for the current build configuration, then switch to uppercase to actually use it.

I don't know the reasons for the "case insensitive" error - of course I am in Windows so the file system is case insensitive, but... why is that a problem for this package? (I haven't tried other packages yet)

[TheJare]

I assume this is the same type of problem as you already dealt with in https://github.com/conan-io/conan/issues/1557, so feel free to close.

[memsharded]

Yes, you nailed it.

Windows case-insensitivenes is very problematic, specially when packages change name case, and this is the case, bincrafters decided to rename the package to lowercase. We have added a couple of checks in the codebase, IIRC mainly for conan-create, to fail fast and tell the user about the conflict. But those checks might be worth investigating if possible to apply them also for installs, I'll check.

Of course, the typical workaround of switch off & on (in this case remove the cache files with conan remove "*" -f) should be enough.